Outcome
By the end of this lesson, you will be able to map ZopNight audit-log queries to specific SOC 2 and ISO 27001 controls, collect reproducible evidence on demand, and recognize the boundary between what the audit log proves and what supplementary evidence is needed.
| Prerequisites | M4.3.L1-L3 (audit log structure + querying) |
| Time | 9 minutes |
1. Concept
A compliance framework is a list of controls: things your company says it does. An audit checks whether you actually do them.
For changes made through ZopNight (permissions, members, cloud-account connections, schedules, budgets and the rest), the audit log is one source of evidence. It does not certify anything on its own; it gives you records an auditor can sample.
Each control you want to evidence becomes a filter. Running that filter while the auditor watches, and exporting the result, is the evidence.
The discipline is not in collecting evidence at audit time: it is in knowing the filters in advance so you can run them on demand without scrambling.
SOC 2: evidence this log can support
The access-related SOC 2 criteria sit in CC6 (logical and physical access). CC7 covers system operations and CC8 change management.
CRITERION (SOC 2, 2017 TSC) FILTER THAT PRODUCES SUPPORTING EVIDENCE──────────────────────────────────────────────────────────────────CC6.1: Logical access security resource contains "roles"; 12-month date range → every change to role definitions, with who and when
CC6.2: Registering and authorising resource contains "users", users method = POST → people added, by whom, when
CC6.3: Granting, changing and resource contains "assignments" removing access and "teams"; method POST / PUT / DELETE → every role grant, change and removal
CC7.2: Monitoring for anomalies status = failed; source = mcp → failed changes, and every assistant tool call, to review
CC8.1: Change management resource contains "schedules", "budgets", "resource-groups", etc. → the operational change logTwo things this log cannot evidence, so plan other sources: sign-in events (sign-in runs in ZopNight’s external auth service and is not in the org audit log), and SSO configuration changes (made by ZopNight staff for your domain, not through your org’s API).
ISO/IEC 27001:2022: evidence this log can support
The 2022 edition numbers its Annex A controls A.5 to A.8. (The older A.9, A.12, A.16 and A.18 numbering is from the 2013 edition, which is no longer used for new certifications.)
ANNEX A CONTROL (2022) FILTER THAT PRODUCES SUPPORTING EVIDENCE──────────────────────────────────────────────────────────────────A.5.15 to A.5.18: Access control, Same filters as SOC 2 CC6.1 to identity management, access rights CC6.3: roles, users, assignments, teams
A.8.15: Logging The audit log itself: show that changes are recorded with who, what and when
A.8.32: Change management Any mutation across resources, schedules, budgets, groups; date range = the audit window
A.5.24 to A.5.28: Incident management Entries around the incident (incl. A.5.28 collection of evidence) window, exported as CSV and attached to the incident recordTreat these mappings as a starting point for your own control matrix. Whether a control is met is your auditor’s judgement, made across all your evidence.
Evidence collection workflow
The pattern that works:
1. AUDITOR ASKS: "How do you control who can change cloud-account credentials?"
2. YOU ANSWER: "Only roles holding cloud-account:update can, and by default that is Admin. The audit log records every change. Let me show you."
3. YOU RUN THE FILTER (Activity → Audit Logs): resource contains "cloud-accounts" method = PUT (credential updates) or DELETE (removals) date range = last 12 months
4. RESULT: Every matching change. Each row shows the timestamp, the user, the account's path and success or failure. The bodies are not stored for cloud accounts, by design, so no secret is exposed.
5. AUDITOR REVIEWS A SAMPLE: Pick 3-5 rows. To show each user's role at that time, filter on resource contains "assignments" and that user's email, and read the most recent assignment before the change.
6. EVIDENCE COLLECTED: Export the filtered view as CSV (it arrives by email) and attach it to the evidence package.
7. AUDITOR CAN REPRODUCE: If they have read access to the audit log themselves (a role holding audit-log:view), they re-run the filter. Seeing everyone's rows also needs organisation:view; without it, the Audit Logs page shows only the auditor's own rows.Reproducibility is the gold standard. An auditor who can re-run the filter in real time is far more satisfied than one who has to trust a screenshot.
What the audit log CANNOT prove
Knowing the limits is as important as knowing what works:
NOT EVIDENCE FROM AUDIT LOG ALTERNATE EVIDENCE──────────────────────────────────────────────────────────────────WHY a change was made (intent) Slack thread, ticket comment, change request
Manual processes outside ZopNight Process docs + ticketing system audit trails
Cloud-side actions performed in Cloud-side audit logscloud provider's own console (AWS CloudTrail, GCP Audit Logs, Azure Activity Log)
Conversations during an incident Incident ticket transcripts, recorded meetings
Effectiveness of a control Test results, exception tracking, KPI dashboardsCompliance audits assemble evidence from multiple sources. ZopNight’s audit log covers the user-API-mediated controls; supplementary evidence covers the rest.
Retention for compliance
Your policy and your auditor set the retention period. ZopNight has no purge, so rows stay; export to keep your own copy.
If you are under PCI DSS, the requirement is 12 months of audit history, with the most recent 3 months immediately available (req. 10.5.1). Rows kept in ZopNight meet the “immediately available” part; keep your own exported copy when a framework asks for write-once (WORM) storage or records held under your own control (L3, L5).
What the log does not guarantee
For the audit log to support compliance evidence, you need to be able to describe honestly how it is protected and where its limits are.
WHAT HOLDS WHAT THAT MEANS──────────────────────────────────────────────────────────────────No customer edit or delete The product has no screen or API to edit or delete an audit row
Recorded at the gateway Every app, API and MCP change passes the same audit step
Truncation is provable A cut body keeps its original size and a SHA-256 of the full body
WHAT DOES NOT HOLD──────────────────────────────────────────────────────────────────No hash chain or tamper seal Rows are not chained to each other; ZopNight's own data maintenance has updated and deleted rows in the past
Not append-only at the database It is an ordinary table
Reads of the audit log are not logged Viewing it is not recorded; starting an export is a POST, so that isWhen an auditor asks “how do we know the audit log itself hasn’t been tampered with,” answer with what holds and keep your own exported copies as the independent record. Do not describe the log as tamper-proof.
Building your evidence pack
There is no compliance-report page. Every evidence pack is a set of filters plus exports that you define once and rerun:
EVIDENCE PACK FILTERS TO RUN──────────────────────────────────────────────────────────────────SOC 2 Type II (last 12 months) roles, users, assignments, teams, cloud-accounts, plus the operational change log
ISO 27001 (last 12 months) The same rows, labelled by Annex A control
Quarterly RBAC review roles, assignments, teams for the quarter
Monthly access review users and assignments for the monthThe packs are useful even outside audit season: a quarterly RBAC review surfaces drift before it becomes a finding.
2. Demo
A real-feeling SOC 2 Type II evidence collection:
AUDITOR REQUEST: "Show me 5 examples of cloud-account credential updates from the past 12 months. For each, identify who made the update and confirm they had Admin role at the time."
ZOPNIGHT USER: T+0 Open Activity → Audit Logs T+30 s Filter: method = PUT, resource contains "cloud-accounts", date range = last 12 months T+45 s Result: 23 credential updates across the year T+1 min Click "Export"; the CSV arrives by email T+3 min Open CSV; pick 5 random samples T+4 min For each: note user, time and status (no body is stored for cloud accounts, by design) T+6 min For each: filter resource contains "assignments" and the user's email; the latest assignment before the update shows the role they held T+9 min Screenshot the 5 events + the assignment entries T+10 min Attach the CSV + screenshots to the audit evidence package
SUBMIT to auditor. Audit conversation continues.
ELAPSED: 10 minutes. Reproducible at any time.3. Hands-on (5 min)
Pick one compliance control your org handles (SOC 2 CC6.x, ISO 27001:2022 A.5.15, an internal control, anything). Map it to an audit-log filter:
CONTROL FRAMEWORK + ID: __________CONTROL DESCRIPTION: __________
AUDIT-LOG QUERY THAT PRODUCES EVIDENCE: Filter: __________________________________________________________ Time window: __________ Expected result shape: __________
RUN THE QUERY now. Result count: _____
SUPPLEMENTARY EVIDENCE NEEDED (if any): □ Documented process / runbook □ Ticketing system entries □ Cloud-side audit log □ None: audit log alone proves the control
NEXT AUDIT DATE: __________QUERY OWNER (who runs it for the audit): __________If you cannot map a control to a query, that is a real gap; either the control is not actually mediated by ZopNight (it lives elsewhere), or it is, and you need a query that did not exist before.
4. Knowledge check
Q1
A SOC 2 auditor asks “Show me 3 examples of approval-gated remediations.” The audit log can:
A. Search approve with method = POST, then sample the rows
B. It will not help at all, since the approvals are out of scope
C. It can only show that it happened, and never any of the details
D. It can only be shown via the cloud provider’s own audit logs
Show answer
Correct: A. Approvals are POSTs to paths ending in /steps/<step>/approve, so a search for approve finds them. Return any sample of 3: each entry shows the user, the path, the request and the response, and the auditor can re-run the filter.
Q2
The audit log captures decisions and the reasoning behind them:
A. Yes, with an explicit reason field on every single entry
B. Only when the acting user chooses to supply a reason for it
C. No: the audit log captures what happened (the API calls)
D. Only for the high-risk actions, and not for the routine ones
Show answer
Correct: C. There is no reason field. The why (intent, deliberation, judgment) lives in supplementary sources: Slack threads, ticket comments, change requests. Compliance audits assemble evidence from several sources, and the audit log is one input.
Q3
For a financial-services org whose auditor sets a 7-year retention period:
A. Nothing to configure: rows are kept indefinitely
B. The default 1-year retention is sufficient
C. Cannot be done in ZopNight
D. Use cloud-side audit only
Show answer
Correct: A. ZopNight keeps audit rows indefinitely and has no retention setting, so seven years is covered without configuration. If the framework also requires write-once (WORM) storage under your control, export regularly and archive the CSVs yourself.
5. Apply
Write your evidence packs down as named filters in your compliance runbook, one per control, and run them from Activity → Audit Logs with a CSV export.
Schedule a quarterly internal review of the evidence packs: not just at audit time. Drift between expected and actual control evidence is much easier to fix in a quarter than during an active audit.
Related lessons
- L1: What gets logged
- L2: Body capture trade-offs
- L3: Filtering and export
- T4.M4.1.L1: The policy table
- T4.M4.4.L4: Cross-account isolation vs rollup
Glossary terms touched
Module quiz
Complete M4.3 → 10-question module quiz.