In the previous post, Towards Repeatable Compliance, we explored the basics of a generic framework to define compliance requirements, extract controls and execute them as part of a deterministic verification set.
That is useful on its own, but we can do better by aligning each of the components with industry standards, gaining better integration and reusing existing patterns.
This post starts covering a bit of SOX regulation, and introduces a well-known governance framework (COSO) to structure the requirements, also a set of controls (SCF) to validate them and a standard format for expressing the findings (NIST’s OSCAL).
The concepts
COSO is the framework the SOX assertions are made against.
Published by the Committee of Sponsoring Organizations of the Treadway Commission, it organizes internal control into five components — control environment, risk assessment, control activities, information and communication, and monitoring — expanded into 17 principles. It is a rubric, not a catalog: it says how to judge whether a set of controls is effective, but not which controls to implement. That’s where we bring SCF.
SOX tells you how to judge whether controls are effective but not which controls to implement.
The Secure Controls Framework (SCF) is a free control catalog maintained by the SCF Council: 34 domains, more than 1,500 controls, each one written once and cross-referenced to the equivalent requirement in over 200 laws, regulations and frameworks. Instead of maintaining one control set for SOX, another for ISO 27001 and a third for SOC 2, SCF controls implementation allows reusability across compliance frameworks, for example.
Our controls will generate findings. These can be expressed in a standard machine-readable form. NIST’s Open Security Controls Assessment Language (OSCAL) defines a set of layered models: a catalog holds the controls, a profile selects and tailors the subset that applies to us, a component definition and a system security plan describe how they are implemented, and assessment results carry the findings. OSCAL gives the result verdicts a schema that any tool can read without knowing anything about our database.
The Role of AI
Use AI to convert SOX obligations into requirements, requirements into controls.
And nothing else.
It’s important to understand when to use AI and when not.
For instance, requirements and controls should be fixed and repeatable (deterministic).
As first step, review which part SOX you find relevant for your compliance needs.
Derive a set of requirements out of the identified SOX items and match them with existing COSO principles. Use may use an AI agent for this.
Review your requirements and COSO alignment with a human SME. You may use also an LLM to judge them as part of the reviewing process.
Use AI to map requirements to specific SCF controls.
Implement the SCF controls with AI. This involves analyzing your data sources and data catalogues to create stored procedures.
Ensure your stored procedures generate OSCAL-compatible findings. AI agents can help with this.
Refer to Figure 1. in Towards Repeatable Compliance for an illustrated example.
An example: Intercompany Reconciliation
Intercompany reconciliation is one of the highest-risk areas in corporate accounting, and a standing focus of SOX 404 audits.
A parent company with subsidiaries — say a US parent, a manufacturing arm in Ireland and a distributor in Germany — has those entities constantly selling, lending and transferring among themselves.
A group cannot book profit on selling to itself, so intercompany transactions must be eliminated on consolidation.
The elimination only works if both sides recorded the same thing.
If the Irish entity books a $10M sale to the German entity and the German entity never books the purchase, the consolidated balance sheet is inconsistent: revenue never earned outside the group, and an intercompany receivable with no payable against it.
There are several reasons that cause a break. These are some:
timing — goods shipped in December, received in January
currency — each side translating at its own rate
mismatched accounts — the same transaction booked to different GL accounts
What starts as a reconciliation difference ends as a manual year-end adjustment. This falls out this article scope but it’s part of a more generic subject, financial reconciliation.
From the regulation point of view, intercompany reconciliation success becomes an obligation. Quoting SOX §404(a):
The annual report […] shall contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.
From SOX to COSO
COSO does not say “reconcile your intercompany balances”.
Instead, it determines which kind of control has to exist, and under which component a failure would be reported.
It’s part of your responsibilities to adjust these principles to intercompany reconciliation use case.
From COSO to SCF requirements
This is where the policy becomes more tangible, closer to data validation domain.
Once we identify the COSO principles, we can generate requirements and match them to SCF controls that are related to them.
This is an exercise that can be supported by an AI agent.
We can express the requirements in EARS format (I covered EARS before):
REQ-301 IF the selling entity has not recorded a leg, OR the buying entity has not
recorded a leg, OR either amount is absent in the reporting currency, OR the
two amounts differ by more than 1 USD, THEN the Consolidation Service SHALL
reject the intercompany transaction.
REQ-302 IF the identity that posted an opposing leg is not recorded, OR it is the same
identity that posted the first leg, THEN the Consolidation Service SHALL refuse
the posting.
REQ-303 IF a posted leg does not record the rate, OR does not record the rate source,
OR does not record the timestamp the rate was taken at, THEN the Consolidation
Service SHALL reject the leg.And the same three requirements expressed in Gherkin, which provides clear evidence in case of mismatch:
Scenario: An unmatched intercompany leg blocks consolidation
Given an intercompany reference recorded by the selling entity
When the buying entity has not recorded the opposing leg
Then the reference is reported as unmatched and consolidation is halted
Scenario: One identity cannot post both sides
Given an intercompany reference with a leg in each entity
When the two legs name the same posting identity
Then the reference is reported as a segregation-of-duties breach
Scenario: Every translated amount can be recomputed
Given a posted intercompany leg
When its translation record is read
Then it carries a rate, a source and the timestamp the rate was taken atConclusion
This is the end of the Part I on intercompany reconciliation, where we have set the auditing framework to be implemented and the first sections on SOX, COSO and SCP mapping.
In the next post of the series we’ll explore how to generate stored procedures with a concrete example!