SOX: Internal Control Over Financial Reporting
The Sarbanes–Oxley Act applies to US-listed companies and their subsidiaries. Two sections drive the work.
Section 302 requires the CEO and CFO to certify each periodic report — that they reviewed it, that it contains no material misstatement, and that they are responsible for disclosure controls and have evaluated their effectiveness.
Section 404 is the expensive one. Management must assess and report on the effectiveness of internal control over financial reporting (404(a)), and for accelerated filers the external auditor must attest to it (404(b)).
In practice a SOX programme means:
- Scoping — which entities, accounts and processes are material, refreshed annually against current financials.
- Risk assessment — what could go wrong for each significant account, expressed as specific misstatement risks rather than generic risk labels.
- Control documentation — process narratives or flowcharts, with key controls identified and their assertions mapped.
- Testing — design effectiveness and operating effectiveness, with sample sizes justified by control frequency.
- Deficiency evaluation — classifying findings as deficiency, significant deficiency, or material weakness, and aggregating them.
- Remediation — tracked to closure, with retesting after the fix has operated long enough to sample.
The recurring pain is evidence. Testing requires populations, samples, and retained artefacts, and reconstructing those after year-end is where SOX programmes lose their time.
PCI DSS
PCI DSS applies to any organisation that stores, processes or transmits cardholder data. It is contractual rather than statutory, enforced through the card brands and acquirers.
Validation depends on merchant level and transaction volume: larger merchants require a Report on Compliance from a Qualified Security Assessor, smaller ones a Self-Assessment Questionnaire in one of several variants matched to how you handle card data.
Two practical points dominate. First, scope reduction is the highest-value activity — tokenisation, redirect or hosted payment pages, and network segmentation all remove systems from the cardholder data environment, and every system removed is a system you do not have to secure to PCI standard or evidence annually.
Second, PCI DSS v4.0 moved several requirements toward continuous rather than annual validation, and introduced the customised approach, which allows meeting an objective by a different means provided you document and evidence the rationale. That flexibility comes with a documentation burden of its own.
DORA
The EU Digital Operational Resilience Act applies to a wide range of financial entities and, importantly, to their critical ICT third-party providers. It has been applicable since January 2025.
Its five pillars:
- ICT risk management — a governance framework with management-body accountability, not delegated to IT.
- ICT incident reporting — classification against defined criteria, with initial, intermediate and final reports to the competent authority on a prescribed timeline.
- Digital operational resilience testing — a programme proportionate to size and risk, with threat-led penetration testing for significant entities on a three-yearly basis.
- ICT third-party risk — a Register of Information on all contractual arrangements with ICT providers, mandatory contractual provisions, concentration-risk analysis, and documented exit strategies.
- Information sharing on cyber threats.
The Register of Information deserves specific attention: it is a structured, regulator-submitted dataset covering every ICT contractual arrangement, the functions they support, and criticality assessments. Assembling it from procurement spreadsheets is where most institutions found their gaps.
What These Three Have in Common
Despite different origins, all three demand the same underlying machinery:
- A control framework with owners, frequencies and defined evidence.
- Testing with retained results and exception handling.
- Deficiency tracking through to verified closure.
- Third-party oversight with contractual and continuous assessment.
- An audit trail that survives independent scrutiny.
Because they overlap — access control, change management, incident response and vendor management appear across all three — maintaining a separate control set per regulation triples effort and produces three sets that disagree. One library, mapped to all applicable frameworks, tested once, is the only approach that scales.
Where Programmes Typically Fail
- Evidence assembled retrospectively. Fine for a design test; fatal for operating-effectiveness testing across a period.
- Scope drift. SOX scoping and PCI cardholder-data-environment boundaries both need annual refresh; both quietly expand.
- Deficiencies not aggregated. Individually minor findings can combine into a significant deficiency or material weakness, and nobody notices until the auditor does it for them.
- Third-party assessments as an annual questionnaire. DORA in particular expects ongoing oversight and documented exit strategies, not a filed questionnaire.
- Remediation without retesting. A closed action is not an effective control until it has operated long enough to sample.
How ActiveERM Supports Financial and Sector Regulation
The audit and controls modules hold one control library mapped across SOX, PCI DSS, DORA and any other framework in scope, with testing workflows, sampling, exception tracking and retained evidence. Findings flow into remediation with owners and dates, and retesting is recorded against the original deficiency.
Third-party arrangements are held as structured records rather than documents, which is what makes a DORA Register of Information maintainable. Because the control library is shared with information security and the risk register, an ISO 27001 control that also serves a DORA requirement is tested once.
See also our guides to internal audit and third-party risk management.