A compliance dashboard and an auditor are asking two different questions, and most GRC tooling only answers one of them. The dashboard shows a control as passing the moment a scheduled test runs green. An auditor doing fieldwork wants the timestamped log trail behind that checkmark, and a green light with no gap-free history behind it isn't evidence of anything.
That gap surfaced on a call with our assessor during fieldwork last quarter. She didn't ask whether our controls were configured correctly. She asked for the record: monitoring logs with no unexplained gaps, alert data showing what fired and when, and the trail from alert to resolution. Producing that took real work, not a dashboard export.
In brief:
- Regulators now mandate SOC capabilities by name. PCI DSS 10.4.1.1 requires automated log review mechanisms, and NYDFS §500.14(a)(2) requires endpoint detection and response (EDR) plus centralized logging for Class A companies.
- GRC platforms collect configuration-state evidence, but QSAs can demand proof that controls actually operated, and the SOC is where much of that execution-layer evidence is generated.
- Detection rules don't carry control IDs, so the GRC binder ends up owning the audit narrative.
- One mapping pass from detections and log pipelines to control IDs makes the SOC the evidence source for auditor requests.
The orthodoxy: financial compliance is something you buy or bolt on
Companies often treat financial compliance as picking a framework, buying a compliance automation platform, connecting integrations, and letting automated tests collect evidence. That picture is accurate but incomplete, because it describes evidence about configuration while the controls operate elsewhere. These platforms use API integrations to check configuration state, like multifactor authentication (MFA) enforcement at the identity provider (IdP) or CloudTrail status. A live audit tests the operational layer around that state.
On the security-controls side, financial compliance runs through a set of active processes. Someone has to review logs daily, triage the anomalies, alert on control failures, investigate the alerts, retain the evidence, and review access annually. In every organization I've run security for, the team doing that work is the SOC, and the compliance platform attests to it from the outside. The orthodoxy has the ownership backward.
What the audit actually asks for, and who already runs it
Put the control language from current financial frameworks next to a functioning SOC's daily output, and the overlap covers much of the operational audit. Access control and continuous monitoring carry many of the security-control evidence requests in financial-sector assessments, with change-management records close behind, and the SOC operates those controls.
Access control and least privilege live in the SOC
PCI DSS 7.2.4 requires review of access privileges, including third-party and cloud service accounts, and 7.2.5 requires system accounts managed on a least-privilege basis, both mandatory since March 31, 2025. NYDFS §500.7(a)(4) requires an annual access review with termination of access no longer needed, effective May 1, 2025. A GRC platform may pull the identity and access management (IAM) role list, but it can miss privileges assigned outside IAM through ad-hoc scripts.
DORA goes further, asking for continuous evidence, not a snapshot. Where PCI DSS and NYDFS ask whether the right people still hold access, Article 15 asks the SOC to actively monitor for anomalous behavior in information and communication technology (ICT) risk, through indicators like network use patterns, hours, and unknown devices. In SecOps terms, that becomes identity-detection content in a security information and event management (SIEM) platform, tuned by detection engineers. A configuration-state GRC integration is not where that gets evaluated.
Continuous logging and monitoring is the control
Regulation stopped implying and started naming tools. PCI DSS 10.4.1.1 requires automated log reviews, mandatory since March 31, 2025, which is a SIEM requirement written without the word SIEM. NYDFS §500.14(a)(2) requires Class A companies to implement an EDR solution and centralized alerting as of May 1, 2025. DORA Article 9(1) requires continuous monitoring of ICT security, and GLBA §314.4(c)(8) requires user activity logging and unauthorized-access detection.
From the SecOps seat, the log pipeline, the daily review under PCI 10.4.1, the exception handling under 10.4.3, and the 12-month retention with three months immediately available under 10.5.1 are all the monitoring control operating in the SOC, through review, investigation, and retention.
Change management and alerting already produce the audit trail
PCI DSS 10.7.2 requires that failures of critical security systems, including intrusion detection and prevention (IDS/IPS), audit logging, and anti-malware, are detected, alerted, and addressed promptly. DORA Article 10(2) requires detection mechanisms with defined thresholds and automatic alerts for incident response staff. Every SOC I've run has monitored the health of its own detection stack, because you find out fast when an EDR sensor fleet goes quiet. That habit is now a named regulatory control.
The GLBA Safeguards Rule requires change management procedures at §314.4(c)(7), and change management is one of the four ITGC domains auditors evaluate under the Public Company Accounting Oversight Board's PCAOB AS 2201. A detection engineering team running detection-as-code, with rules in Git and peer-reviewed pull requests, produces a versioned, approver-attributed change record as a byproduct. Expose that audit trail to the auditor.
Why the SOC gets no credit for controls it already operates
If the SOC runs the controls, why does the GRC platform get the audit credit and the renewal budget?
The mapping gap between control language and SOC telemetry
The auditor asks in control IDs, while the SOC answers in correlation search names and MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) techniques. Nothing translates between them by default.
Splunk Enterprise Security maps correlation searches to NIST Cybersecurity Framework (NIST CSF) codes like DE.AE, but NIST Special Publication (SP) 800-53 control IDs need a separate mapping. The official Sigma tag specification defines namespaces for ATT&CK, CVE, and D3FEND, but none for NIST 800-53 or PCI DSS. The SOC does the control work all year, then does the manual translation at audit time while the GRC platform presents the result. Teams routinely lose hours a week to that work.
GRC tooling attests from outside SOC execution
GRC platforms are systems of record, while the SOC tools and workflows are the systems of execution. They verify that CloudTrail is enabled, but review of what it captured lives outside that check, and a broken API connection can leave auditors relying on outdated information. Alert-triage quality, detection-rule efficacy, and investigation depth are all SOC operating questions. The platform attests from the configuration state while the operating evidence sits in the SOC.
I've watched this collapse in the room. During a PCI assessment I ran, the GRC export showed logging enabled across every in-scope account, green everywhere. The QSA set it aside and asked for the daily review evidence and the exceptions we'd chased under 10.4.3, weighting operational proof over configuration. Everything the QSA wanted lived in my team's SIEM, without control IDs, and we spent two weeks translating work we'd already done.
How to claim the credit without adding compliance theater
Annotate existing evidence and route auditor requests to the SOC first. That keeps the work inside the operational systems where the controls already run.
Map existing detections and logs to control IDs once
Use the existing crosswalks to tag your production content. The Center for Threat-Informed Defense publishes over 6,300 mappings between NIST 800-53 controls and ATT&CK techniques, so a program already mapped to ATT&CK is one join from control IDs. The Secure Controls Framework crosswalks 200+ laws and frameworks, including PCI DSS, SOX, GLBA, and DORA, so you tag once and answer many. Then push the IDs into tooling you already run: Splunk's PCI app, Sentinel's NIST 800-53 solution, detection-as-code metadata.
Do it as one scoped effort, then hold the line in code review, where every new detection needs metadata with applicable control IDs. That turns the work into minutes per rule going forward, and existing artifacts become legible to an auditor without a translation sprint.
Make the SOC the source of evidence
Once detections carry control IDs, flip the evidence flow so the QSA's wish list becomes a query against the SOC's case management and SIEM. It covers timestamped logs with no unexplained gaps, alert records with routing and investigation evidence, and alert-to-resolution traces. For SOC 2 Type II CC7.2, point-in-time exports fail, while SIEM-integrated logs with documented baselines supply the operating evidence. Keep the GRC platform for what SOC telemetry doesn't capture, like policy lifecycle and vendor risk.
The stakes for getting this wrong are no longer abstract. NYDFS cited §500.5 continuous-monitoring obligations in the $11.3 million GEICO settlement, and fined Delta Dental $2.25 million over inadequate incident response procedures in April 2026. I write the checks for both line items, and for years I let the smaller one own the audit narrative while the bigger one did the work. The mapping took my team one quarter, once. Do it before your next audit cycle starts.
Frequently asked questions about financial compliance in the SOC
What counts as financial compliance for a SOC?
From the SecOps seat, it's the security-control requirements of financial-sector frameworks: PCI DSS Requirements 7 and 10, NYDFS Part 500, DORA Articles 9, 10, and 15, the GLBA Safeguards Rule at 16 CFR §314.4, and the SOX ITGC domains. Finance-department and accounting compliance sit outside this SOC evidence scope. The overlap with SOC operations concentrates in logging, monitoring, alerting, access review, change management, and retention.
Which SOC controls map to financial compliance requirements?
Automated log review maps to PCI DSS 10.4.1.1, EDR and centralized alerting map to NYDFS §500.14(a)(2) for Class A companies, user activity monitoring maps to GLBA §314.4(c)(8) and DORA Article 10(3), and identity anomaly detection maps to DORA Article 15. Alerting on security-tool failures maps to PCI DSS 10.7.2, and detection-as-code change records support GLBA §314.4(c)(7) and SOX ITGC change management. Log retention maps to PCI DSS 10.5.1's 12-month requirement.
Do we still need a GRC platform if the SOC owns the controls?
Yes. In many programs, GRC platforms remain useful for policy lifecycle management, vendor and third-party risk, HR and training controls, multi-framework gap analysis, and the auditor-facing request portal. What changes is the evidence flow for operational security controls, where the SOC becomes the source and the GRC platform consumes and organizes the SOC's operating evidence.
How do we prove controls we already run to an auditor?
Produce execution evidence: timestamped monitoring logs with no unexplained gaps and alert records showing detection and routing, plus traces from alert through investigation to resolution. For SOC 2 Type II, that evidence must cover the full audit period, because point-in-time exports fail CC7.2. Tag detections and log pipelines with control IDs first, and use crosswalks like the Secure Controls Framework so the evidence answers the auditor's control language.