GASP AICF

Search controls and profiles

Search by control ID, name, domain or profile

MON-009 Log Access Control and Sensitive Data in Logs

Tier 2+ProviderDeployerGPAI Model ProviderManaged Service Provider

Description

Read access to production logs and the ability to change logging configuration are held by named roles, with each grant recorded and reviewed at defined intervals. A read of the log store is itself logged. Secrets, credentials, authentication tokens and personal data beyond what the log entry exists to record are filtered or tokenised in the logging pipeline before the record reaches the log store. Records that reach the store carrying such values are detected on a defined cycle, reported and removed or tokenised. The detection result is retained.

Rationale

Logs are where sensitive data ends up by accident and where an attacker looks first. A log platform everyone can read is a second copy of production data with none of production's access controls. Filtering in the pipeline rather than at query time keeps the secret out of the store in the first place. Scanning for what got past the filter is what makes the filter testable. MON-002 holds tamper resistance, MON-003 retention, DAT-016 the masking rules and AIG-020 the AI prompt and output case. Issued in S4 from G-MON-2 in docs/review-canonical-quality.md section 7.3.

Applicability (9 profiles)

SaaS AI Providerstablerequiredcore
Enterprise AI Deployerstablerequiredcore
GPAI Model Providerstablerequiredcore
High-Risk Provider (EU)stablerequiredcore
Public Body Deployer (EU)stablerequiredcore
DORA ICT Provider (EU)stablerequiredcore
NIS2 Cloud Provider (EU)stablerequiredcore

Framework Mappings (7)

LOG-04Audit Logs Access and Accountabilityfull
LOG-08Audit Logs Sanitizationpartial
LOG-04Audit Logs Access and Accountabilityfull
LOG-08Audit Logs Sanitizationpartial
AU-9Protection of Audit Informationinformative
AU-9(4)Protection of Audit Information | Access by Subset of Privileged Usersfull
LLM02Sensitive Information Disclosureinformative

Evidence (3)

configurationtechnicalautomated

Role and permission configuration of the log platform showing which roles can read production logs, which can change logging configuration and which accounts hold each role.

Example: Log platform role assignment export of 2026-08-22 listing the four roles with log read access, the two with logging configuration rights and the accounts assigned to each

Test: Export the log platform role and permission configuration. Verify: (1) read access to production logs is held by named roles rather than by a default that every engineer inherits, (2) the ability to change logging configuration is held by a smaller set than read access, (3) every account holding either role has a recorded grant, (4) reads of the log store are themselves recorded in an audit trail the log platform produces.

tool_outputtechnicalautomated

Output of a scan over a sample of the log store for secrets, credentials, tokens and personal data, with each finding traced to the pipeline rule that should have filtered it.

Example: Log content scan report of 2026-08-10 over seven days of production log volume, listing 23 findings by pattern class with the filter rule each bypassed and the removal ticket raised

Test: Run the scan over a defined window of the production log store. Verify: (1) the scan covers every log stream that reaches the store, including application, infrastructure and third-party streams, (2) it tests for credential and token patterns as well as personal data patterns, (3) every finding was removed or tokenised and the filter changed so the same pattern does not recur, (4) the scan runs on the defined cycle and its results are retained.

recorddocumentmanual

Access review record for the log platform roles showing who was reviewed, what was removed and who approved the remaining grants.

Example: Log platform access review of 2026-07-15 covering 38 accounts, with 6 removals actioned and the reviewing owner recorded per role

Test: Take the most recent access review for the log platform. Verify: (1) it was performed within the defined interval, (2) it covers read access and logging configuration rights separately, (3) removals raised by the review were actioned and the current role assignments reflect them, (4) the reviewer is someone other than the account holder being reviewed.

Questions (3)

boolean

Is read access to production logs restricted to named roles?

Answer no where every engineer inherits log read access from a general production role. The question is about the log platform, not about the systems that produce the logs.

multi

Which of the following apply to your logging pipeline and log store?

Secrets, credentials and tokens are filtered before a record reaches the storePersonal data beyond the entry's purpose is filtered or tokenised before a record reaches the storeThe store is scanned for values that got past the filterReads of the log store are themselves loggedChanges to logging configuration are restricted to a smaller set of roles than log readsNone of the above

Filtering before the record reaches the store is different from masking it in a query or a dashboard, which leaves the value in the store. Answer against the pipeline as it runs, not against the logging standard.

select

How often are log platform access grants reviewed?

At least quarterly, with removals actioned before the next reviewAt least annually, with removals actioned before the next reviewWhen someone raises a concernGrants are not reviewed after they are made

Options run from strongest to weakest. A review that produces findings nobody actions is not a review; the removals are the test.