I've sat through three governance, risk, and compliance (GRC) platform demos in the past year, and every one ended on the same slide: a wall of green checkmarks fed by screenshots. None of them showed where those screenshots came from.
In my org, they came from a security operations center (SOC) analyst pausing real work to capture a security information and event management (SIEM) dashboard that our ticketing integration was already documenting, alert by alert, with timestamps and investigation notes.
We were paying once to generate that evidence in production and again to reconstruct it for the audit binder.
Reconstructing evidence forces any ISO 27001 SOC program to pay twice. The SANS 2025 Detection Engineering Survey puts a number on the underlying squeeze: 71% of respondents cite resource and time constraints as their primary organizational obstacle, which matches my own budget line, where every hour spent reconstructing evidence is an hour the team can't spend improving detection.
In brief:
- I organize SOC evidence around nine Annex A controls that map to functions a working SOC already runs, treating two of them, 5.7 threat intelligence and 8.16 monitoring activities, as added focus areas in the 2022 revision.
- For 8.16, I build an evidence chain from alert trigger to investigation ticket to tuning decision; a log archive nobody reviews doesn't demonstrate an operating monitoring process.
- Evidence generated by the workflow, such as Git history, security orchestration, automation, and response (SOAR) audit trails, and continuous integration and continuous delivery (CI/CD) records, beats screenshots on the criteria auditors probe. This approach only covers technical controls.
- Hiring a managed detection and response (MDR) provider transfers the operational work but not the accountability. I keep 8.16 and 5.24 on the customer's Statement of Applicability, with the customer accountable for oversight.
The mapping takes an afternoon; the evidence model is the real decision
A textbook ISO 27001-to-SOC crosswalk puts Annex A control numbers down one column, SOC functions across the top, and an owner in every cell. The crosswalk itself is an afternoon of work, and it decides nothing.
The real question is the one the spreadsheet never asks: does evidence for each mapped control get generated by production systems as a byproduct of the work, or reconstructed by humans every audit cycle?
My approach to GRC engineering reverses the usual order. I start from the telemetry, logs, and configuration state that production systems already retain, then map that operating record back to the compliance requirements.
For a SOC, that reversal is the whole game: your SIEM, ticketing system, and detection repo are already producing most of what an auditor wants, and the work is wiring those records into the audit process.
Nine controls, and how I map the SOC to them
My crosswalk turns nine ISO 27001 Annex A controls into an operating model for the SOC: six existing responsibilities, one evolved shared responsibility, and two areas of added focus in the 2022 revision. Some are direct SOC responsibilities, while others require shared ownership with vulnerability management, IT operations, and security leadership.
Six controls map to work a SOC already runs, so I treat them as existing focus:
- 5.24 - incident management planning and playbook development: IR planning
- 5.25 - assessment and decision on information security events: alert triage and L1/L2 analysis
- 5.26 - response to information security incidents
- 5.27 - learning from information security incidents: post-incident review
- 5.28 - collection of evidence: forensics and evidence handling
- 8.15 - logging: log management and SIEM ingestion
I treat 8.8 - management of technical vulnerabilities, as an evolved focus. It brings the SOC into a more formal shared workflow for vulnerability scanning, patch service-level agreement (SLA) tracking, and penetration-testing coordination.
Two controls receive added focus in the 2022 revision. 5.7 - threat intelligence, supports both detection engineering under 8.16 and playbook development under 5.24. 8.16 - monitoring activities, covering SIEM, user and entity behavior analytics (UEBA), baselining, and alerting. This is where I operate 8.15 and 8.16 as one end-to-end logging-and-monitoring process.
Together, these controls form an incident-response chain: planning and preparation lead into event assessment, response, evidence preservation, and post-incident learning.
I prepare chains, not checkboxes
For 8.16, I prepare a paper trail, because the volume of stored logs alone proves nothing. The trail has three parts: an alert that fired recently, a ticket showing who investigated it and what they did, and proof I've adjusted thresholds to reduce false positives.
For 5.25, I prepare for an auditor to sample recent events and check that closed ones carry a rationale, so I document a false positive as an explicit assessment result before closing the event.
The language of the evidence matters as much as its existence. A statement that a review was completed is weaker than a record naming the date and the assigned owner, with completion evidence filed.
For surveillance audits, I also check for stagnant evidence, inactive owners, and risk treatment plans that never change, because a monitoring program that was live at certification and coasted since is exposed in year two.
Screenshots vs. pipelines: the comparison on my audit criteria
Screenshots are cheap, auditors I've worked with have accepted them, and for governance-side evidence like management review minutes they're often the only option.
Where they break is the information-produced-by-the-entity (IPE) problem: when a company produces evidence about itself, an auditor asks whether the report is complete, accurate, and free of query parameters that excluded relevant data. A screenshot can't answer any of that, and I've seen outdated screenshots from previous system configurations sit unnoticed in GRC platforms.
Pipeline evidence answers those questions structurally. With branch protection and signed commits, the Git record of author, timing, content, and rationale is a stronger A.8.32 change-management trail.
For infrastructure, I assemble the declared configuration, the review record, proof of deployment, and later drift results into one package that shows both what was approved and whether the environment stayed aligned. A screenshot captures one moment.
As the person who signs both the GRC contract and the SIEM renewal, I choose pipeline evidence for 8.8, 8.15, 8.16, and 8.32 because it covers the full audit period and wins on marginal cost.
SANS survey data suggests many teams are partway there: version control for detection rules is more common than CI/CD pipeline integration, and that pipeline step is the component that turns detection work into repeatable audit evidence.
Where the pipeline doesn't reach
Runtime evidence covers detection, response, and vulnerability handling. Records for business continuity, backup policy, multifactor authentication (MFA) as a program, human resources (HR) training, and governance controls still need humans producing them the old way.
Automating framework evidence leaves the business-risk decisions to people, and automation shouldn't be mistaken for maturity.
I've watched startups move through a compliance platform and get a report without building a real security program, because the hardest parts still need human judgment. That boundary is why I reserve automated evidence for the operating record and keep human judgment in the risk process.
Automating evidence collection for the nine SOC controls is worth doing precisely because it frees the humans for triage judgment, root-cause analysis, and the corrective actions under Clause 10.2.
The customer remains accountable for its MDR
Outsourcing changes the control boundary but not the accountability. Even when an MDR runs the monitoring, I require the customer to define risk appetite and monitoring scope under 8.16, and escalation protocols and incident-lifecycle documentation under 5.24.
I manage the MDR through the supplier-control family (5.19 to 5.23), and I require the contract to address incident-notification windows, audit rights, and subcontractor disclosure.
When I ran my last MDR evaluation, I put two evidence requests into the request for proposal (RFP) before any capability questions, because they're what I show my auditor: the provider's SOC 2 Type II report covering monitoring controls, and a recent alert investigation showing the timeline from detection to resolution.
Expel is one example of an MDR that positions its service around continuous monitoring, detailed incident documentation, and compliance evidence, and in my evaluation those claims would still have to survive the same two requests.
I also ask providers to make audit reports available under a non-disclosure agreement (NDA), and I treat the word "promptly" in place of a defined notification window as the kind of ambiguity an auditor will probe.
One heatmap serves the auditor and the detection team
I haven't found an authoritative direct ISO 27001-to-MITRE ATT&CK mapping, so my workaround chains two: an internal mapping from National Institute of Standards and Technology (NIST) 800-53 to ATT&CK, joined to NIST 800-53's own crosswalk to ISO 27001:2022. The chain takes two steps instead of one, but it keeps detection coverage and control coverage in a single view.
My workflow starts with a small set of threat groups relevant to the sector rather than the full matrix. I tag each detection rule with technique IDs, then score coverage by confidence, because a noisy heuristic and a high-fidelity behavioral analytic shouldn't carry the same weight.
The resulting coverage artifact serves every audience: leadership and auditors read it as control coverage, and engineers work from it as detection coverage.
What to do before the next audit cycle
Run one trace this week. Pull an alert from the last 90 days and follow it from trigger to ticket to tuning decision. Every break in that chain creates duplicate work, whether it's an approval left only in Slack or a false positive closed without a rationale, and most of those breaks can be fixed with a connector and a process tweak on existing headcount.
I've stopped taking GRC demos that open with the checkmark dashboard. The first question I ask now is which production systems the evidence comes from, and how the vendor would prove to my auditor that the export was complete. The ones who can answer get the hour.
Frequently asked questions about mapping ISO 27001 to the SOC
Which ISO 27001 controls do I assign to a SOC team?
I organize SOC evidence around nine Annex A controls: 5.7 threat intelligence, the 5.24 to 5.28 incident-management chain, 8.8 technical vulnerabilities, 8.15 logging, and 8.16 monitoring activities. In the 2022 revision, 5.7 and 8.16 get added focus, while the incident chain stays part of the SOC's established operating model.
Does using an MDR satisfy ISO 27001 monitoring requirements?
An MDR can perform the operational monitoring, but I keep 8.16 and 5.24 on the customer's Statement of Applicability, with the customer accountable for oversight.
I manage the provider through the supplier controls and ask for contractual notification windows, a right to audit, and its SOC 2 Type II report on file, alongside evidence of an actual alert investigation the provider ran.
Can Git history and detection-as-code artifacts be ISO 27001 audit evidence?
For technical controls, yes, when the artifacts demonstrate how the control operated. I use pull request (PR) history with approvers and passing checks as evidence for A.8.32 change management, CI test and deployment logs for 8.16, and infrastructure-as-code (IaC) state files showing log ingestion for 8.15.
I don't assume acceptance from the format alone; I prepare the records around the IPE criteria: traceable to the source system, complete for the period, accurately scoped, and timestamped.
How much evidence overlap is there between ISO 27001 and SOC 2?
Overlap estimates vary because controls are counted at different granularities. The useful overlap concentrates where SOCs operate: our internal working crosswalk treats SOC 2 criterion CC7.2 as aligned with A.8.15 and A.8.16, and CC7.3 as aligned with A.5.24 and A.5.25.
It's an internal alignment, not an authoritative equivalence, so we collect the monitoring and incident evidence once and file it against both frameworks where our auditor agrees it supports each requirement.
What evidence do I prepare for ISO 27001 control 8.16?
Proof an alert fired recently, and a ticket or log entry naming who investigated it and what they did. The trail also includes threshold adjustments that cut false positives over time. My evidence pack can include SIEM dashboards and configured alert rules plus a sample of resolved security tickets tied to documented SOC procedures.
I'd also treat limited monitoring coverage or a missing escalation path from alert to incident as gaps that need remediation.