Skip to the mapping
← auditlog.dev

CC6 and CC7, as events you can query.

A control description is a sentence about what your system does. A sample test is a request for rows. This is the translation between them: for each criterion, the event names that carry it and the filter that produces the sample — so that answering an auditor is a query someone runs rather than a week someone loses.

Every query below is executed against the same 43-event log the five theses are built on, at build time. The counts are not typed by hand, and a mapping that pointed at events the log does not produce would show zero rows here rather than reading as if it worked.

The criteria are paraphrased, not quoted — your auditor will read them from the source. What is worth writing down is what each one asks your system to be able to show, and where the log stops being able to show it. Every entry below that has a limit says so.

  1. CC6.1

    Who gets in, and how

    That access to the system is protected by authentication you can describe and demonstrate — not just configured, but observably in force during the period under review.

    Events

    • auth.login_succeeded
    • auth.login_failed
    • auth.mfa_enabled
    • workspace.sso_enabled

    Sample test

    For the period, show authentication events and their outcomes.
    action:auth.* created:2026-038 of 43 events
    Show when SSO enforcement was turned on, by whom, and what it changed.
    action:workspace.sso_enabled1 of 43 events

    Where the log stops
    The events prove the setting was changed and that logins behaved accordingly. They do not prove the identity provider was itself configured correctly — that evidence lives in the IdP, and its own audit log is the thing to ask for.

  2. CC6.2

    Credentials are issued, not assumed

    That every credential — human or machine — was created deliberately, for a named requester, and that you can walk the trail from request to working account.

    Events

    • member.invited
    • member.joined
    • api_key.created

    Sample test

    For a member added in the period, show the invitation, who sent it, and the acceptance.
    action:member.invited action:member.joined2 of 43 events
    For each API key, show its creation and the scopes it was granted on day one.
    action:api_key.created1 of 43 events

    Where the log stops
    The invitation is evidence that access was granted; it is not evidence that it was approved. If your process has an approval step, the ticket reference belongs in the event's metadata at the moment of the write — otherwise this sample ends in a screenshot of a Slack thread.

  3. CC6.3

    Least privilege, and every move away from it

    That authorization is based on roles, and that every change to what someone or something can do is recorded with enough detail to say what the privilege was before.

    Events

    • member.role_updated
    • api_key.scopes_updated
    • member.removed
    • api_key.revoked
    • auth.sessions_revoked

    Sample test

    Show every privilege change in the period, with the value before and after.
    changed:role changed:scopes8 of 43 events
    Show every access removal, and that the sessions behind it died with it.
    action:member.removed action:api_key.revoked action:auth.sessions_revoked3 of 43 events

    Where the log stops
    This shows that a privilege changed and who changed it. Whether it should have changed is the access review, which is a different artifact with a different cadence — the log makes that review possible, and does not replace it.

  4. CC6.5

    Disposal that leaves a record

    That when data is destroyed on request or at end of life, the destruction itself is evidenced — and that evidencing it does not quietly recreate what was destroyed.

    Events

    • member.data_erased

    Sample test

    Show that an erasure request was carried out, and what it reached.
    action:member.data_erased1 of 43 events

    Where the log stops
    Read the event's own diff on the page: `before` is null on purpose. An erasure event that recorded the address it erased would be a permanent copy of the thing the request was to destroy, filed in the one table you are not allowed to delete from.

  5. CC6.6

    Pressure from outside the boundary

    That attempts to reach the system from outside are detected and refused, and that you can show the refusals rather than assert them.

    Events

    • auth.login_failed
    • auth.login_blocked

    Sample test

    Show failed authentication attempts and what the system did after them.
    action:auth.* outcome:denied4 of 43 events
    Show authentication traffic from outside the countries the workspace operates in.
    action:auth.* country:RU3 of 43 events

    Where the log stops
    These are the attempts that reached the application. Anything stopped at the CDN, the WAF, or the load balancer never became an event here, so this sample is one layer of a picture that has at least two.

  6. CC6.7

    Data leaving the system

    That the movement of data out of the system is restricted to authorized users and is itself recorded — including movement of the audit log.

    Events

    • audit_log.viewed
    • audit_log.exported

    Sample test

    Show everyone who read or exported the audit log, and what they took.
    action:audit_log.*4 of 43 events

    Where the log stops
    The export is logged; the CSV is not. Once the file leaves, its life is governed by your data handling policy and not by this table — which is exactly why the row recording who took it matters.

  7. CC7.1

    Configuration changes are visible

    That changes to the configuration of monitored systems are detected, and that a change can be described precisely rather than as the fact that something was edited.

    Events

    • monitor.created
    • monitor.updated
    • monitor.paused
    • monitor.deleted
    • notifier.created
    • notifier.updated
    • status_page.domain_updated

    Sample test

    Show every change to monitoring and alerting configuration in the period.
    action:monitor.* action:notifier.*11 of 43 events
    Show changes that altered how often a check runs or where it runs from.
    changed:interval_s changed:regions6 of 43 events

    Where the log stops
    The second sample is only answerable because changed_fields is written beside the diff. A log that stored the diff alone would make this a spreadsheet exercise over every configuration event in the period.

  8. CC7.2

    Anomalies, including the ones you refused

    That the system is monitored for behaviour outside the expected, and that the evidence of detection is retrievable for a specific window.

    Events

    • outcome: denied on any action
    • impersonation.started
    • impersonation.ended

    Sample test

    Show every action the system refused, and which control refused it.
    outcome:denied8 of 43 events
    Show every support session that entered a customer workspace, with both identities.
    actor_type:impersonation4 of 43 events

    Where the log stops
    Detection is not response. This sample shows the refusals were recorded; whether anyone was alerted to them is the small set of events worth paging on, and that list belongs in your alerting configuration.

  9. CC7.3 / CC7.4

    Incidents, from acknowledged to closed

    That security and availability events are evaluated, that response is timely, and that the timeline can be reconstructed afterwards from something other than memory.

    Events

    • incident.acknowledged
    • incident.resolved

    Sample test

    For an incident in the period, show acknowledgement, resolution, and the elapsed time.
    action:incident.*2 of 43 events

    Where the log stops
    The timeline comes from the events. The judgement — what it was, what caused it, what changed afterwards — comes from the postmortem, and the two are only worth having together.