Control template: SOX 404 IT General Controls (ITGC)
Status: Public Beta · Version: sox-itgc/v0.1.0-beta
A bundle of CALM control snippets covering the architecturally
enforceable subset of IT General Controls that Sarbanes-Oxley
Section 404 auditors test for US-listed public companies. You copy
these into your *.calm.json files on the nodes that participate
in financial-reporting-relevant systems.
Who SOX 404 ITGC applies to
US-listed public companies (and their controlled subsidiaries) under SEC oversight, plus foreign private issuers filing 20-F. Section 404 mandates management's assessment of internal controls over financial reporting (ICFR), and Section 404(b) requires an external auditor to attest to that assessment (subject to non-accelerated-filer exemptions).
IT General Controls are the ITGC subset of ICFR — the foundational controls over systems that produce or affect financial-reporting data. The four classical ITGC domains:
- Change Management — code, schema, config changes to in-scope systems
- Access Management — who can access financial systems and data
- Operations — backup, monitoring, incident response for financial systems
- Program Development — SDLC for new financial-system code (often grouped with Change Management)
What this template covers
The architecturally enforceable subset. Process controls (approval workflows, periodic access reviews, separation-of-duties matrices) belong in your SOX framework documentation, not your CALM.
| ITGC Domain | Architectural surface | Control alias |
|---|---|---|
| Change Management | All changes via PR review | sox-itgc-change-via-pr |
| Change Management | Code review required (≥1 reviewer) | sox-itgc-code-review-required |
| Change Management | Deployment approval declared | sox-itgc-deployment-approval |
| Access Management | Authentication declared | sox-itgc-authentication |
| Access Management | MFA on financial systems | sox-itgc-mfa-on-financial |
| Access Management | RBAC for financial functions | sox-itgc-rbac |
| Access Management | Privileged-access logging | sox-itgc-privileged-access-logging |
| Operations | Backup and recovery | sox-itgc-backup-recovery |
| Operations | Monitoring and alerting | sox-itgc-monitoring |
| Operations | Incident response process | sox-itgc-incident-response |
| Segregation of Duties | Developer ≠ Approver ≠ Deployer | sox-itgc-sod |
The "in-scope" node pattern
A node is SOX-in-scope if it produces, modifies, or significantly influences financial-reporting data (general ledger, sub-ledgers, revenue / expense / asset registers, consolidation tooling, etc.). Tag those nodes:
{
"unique-id": "general-ledger-service",
"node-type": "service",
"name": "General Ledger Service",
"metadata": {
"sox-in-scope": true,
"financial-data-classification": "icfr-material",
"data-classification": "confidential"
}
}
Then attach the relevant controls below. Your auditor decides what's in scope; ArchRails just enforces what you author.
Control snippets
Copy each block under the controls key of the node it applies to.
Change Mgmt — All changes via PR review (sox-itgc-change-via-pr)
Graph-level. Declare that the firm's policy is no direct pushes to production; every change flows through a PR. ArchRails records the declaration; the runtime gate is the branch-protection on the financial-system repos.
"metadata": {
"controls": {
"sox-itgc-change-via-pr": {
"description": "SOX ITGC — every change to financial-reporting systems is reviewed via PR before merge. Direct push to protected branches is forbidden.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/change-via-pr",
"config": {
"control-id": "sox-itgc-change-via-pr",
"protected-branches": ["main", "production"],
"direct-push-allowed": false,
"policy-document-url": "https://internal.example.com/sox/change-mgmt-policy"
}
}
]
}
}
}
Change Mgmt — Code review required (sox-itgc-code-review-required)
Per-node or graph-level. Declares the reviewer count + that reviewer must not be the author.
"sox-itgc-code-review-required": {
"description": "SOX ITGC — code review by at least one independent reviewer before merge into financial-system branches.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/code-review-required",
"config": {
"control-id": "sox-itgc-code-review-required",
"minimum-reviewers": 1,
"reviewer-cannot-be-author": true,
"evidence-retention": "github-pr-history"
}
}
]
}
Change Mgmt — Deployment approval (sox-itgc-deployment-approval)
Per-node. Declares that production deployment requires an approval gate distinct from the developer who wrote the code.
"sox-itgc-deployment-approval": {
"description": "SOX ITGC — deployment to production requires an explicit approval from a role distinct from the developer.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/deployment-approval",
"config": {
"control-id": "sox-itgc-deployment-approval",
"approver-role": "release-manager",
"approver-cannot-be-author": true,
"approval-mechanism": "github-environments-required-reviewers",
"approval-evidence-url": "https://internal.example.com/sox/deployment-log"
}
}
]
}
Access Mgmt — Authentication (sox-itgc-authentication)
Per-node.
"sox-itgc-authentication": {
"description": "SOX ITGC — authentication mechanism declared for this financial-system node.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/authentication",
"config": {
"control-id": "sox-itgc-authentication",
"mechanism": "saml-sso",
"identity-provider": "okta",
"session-timeout-minutes": 30
}
}
]
}
Access Mgmt — MFA on financial systems (sox-itgc-mfa-on-financial)
Per-node. Same shape as pci-mfa-required but with SOX framing.
"sox-itgc-mfa-on-financial": {
"description": "SOX ITGC — MFA required for all access to financial-reporting-relevant nodes.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/mfa-on-financial",
"config": {
"control-id": "sox-itgc-mfa-on-financial",
"factor-count": 2,
"factor-types": ["password", "totp-or-webauthn"],
"exemption-allowed": false
}
}
]
}
Access Mgmt — RBAC (sox-itgc-rbac)
Per-node.
"sox-itgc-rbac": {
"description": "SOX ITGC — role-based access control restricts financial-data access by job function.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/rbac",
"config": {
"control-id": "sox-itgc-rbac",
"allowed-roles": ["finance-read", "finance-write", "finance-admin"],
"principle": "least-privilege",
"review-frequency": "quarterly",
"review-document-url": "https://internal.example.com/sox/access-reviews"
}
}
]
}
Access Mgmt — Privileged-access logging (sox-itgc-privileged-access-logging)
Per-node.
"sox-itgc-privileged-access-logging": {
"description": "SOX ITGC — privileged-access events (admin login, role grant, role revoke, sudo / db DDL / config change) logged immutably for audit reconstruction.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/privileged-access-logging",
"config": {
"control-id": "sox-itgc-privileged-access-logging",
"events": ["admin-login", "role-grant", "role-revoke", "config-change", "ddl", "data-export"],
"destination": "centralized-siem",
"immutable": true,
"retention-days": 2557
}
}
]
}
Note on retention: 2557 days = 7 years. SOX records retention for audit workpapers is governed by SEC Rule 17a-4 (broker-dealers, 6 years), 17 CFR §210.2-06 (issuers, 7 years), and your firm's record-retention policy. Tune to your retention schedule.
Operations — Backup and recovery (sox-itgc-backup-recovery)
Per-node.
"sox-itgc-backup-recovery": {
"description": "SOX ITGC — backup and recovery procedures for financial-reporting data. RPO/RTO documented and tested.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/backup-recovery",
"config": {
"control-id": "sox-itgc-backup-recovery",
"rpo-minutes": 60,
"rto-minutes": 240,
"backup-frequency": "daily",
"backup-encryption-at-rest": true,
"restoration-test-frequency": "semi-annual",
"last-restoration-test-date": "2025-04-15"
}
}
]
}
Operations — Monitoring (sox-itgc-monitoring)
Per-node.
"sox-itgc-monitoring": {
"description": "SOX ITGC — operational monitoring with alert thresholds for financial-system health and integrity.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/monitoring",
"config": {
"control-id": "sox-itgc-monitoring",
"metrics": ["uptime", "error-rate", "transaction-volume", "data-integrity-checks"],
"alerting-target": "ops-soc@example.com",
"runbook-url": "https://internal.example.com/sox/runbooks/financial-systems"
}
}
]
}
Operations — Incident response (sox-itgc-incident-response)
Graph-level.
"metadata": {
"controls": {
"sox-itgc-incident-response": {
"description": "SOX ITGC — formal incident-response plan covering financial-system disruptions or integrity events.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/incident-response",
"config": {
"control-id": "sox-itgc-incident-response",
"plan-document-url": "https://internal.example.com/sox/ir-plan-financial",
"tested-annually": true,
"last-test-date": "2025-02-20",
"audit-trail-required": true
}
}
]
}
}
}
Segregation of Duties — Dev ≠ Approver ≠ Deployer (sox-itgc-sod)
Per-node. Declares the SoD policy on this financial node. Combines
with sox-itgc-code-review-required and sox-itgc-deployment-approval
to form the classical SoD triangle.
"sox-itgc-sod": {
"description": "SOX ITGC Segregation of Duties — the developer who writes a change must not be the same person who approves the PR or who deploys to production.",
"requirements": [
{
"requirement-url": "https://archrails.io/catalog/req/sox-itgc/sod",
"config": {
"control-id": "sox-itgc-sod",
"developer-approver-disjoint": true,
"developer-deployer-disjoint": true,
"exception-policy-url": "https://internal.example.com/sox/sod-exceptions",
"exception-approval-required": true
}
}
]
}
Note: ArchRails records the declaration that SoD is enforced. The runtime enforcement (GitHub branch protection rules, deployment approver requirements, etc.) is configured at the platform / repo level — your auditor tests both the declaration and the runtime evidence.
What the engine enforces
Same constraint engine that handles PCI / DORA / your own controls. Per-rule behavior:
- Presence-shape rules (MFA, RBAC, authentication, monitoring,
etc.): the engine fires a finding when a
sox-in-scope: truenode does NOT declare the corresponding control. - Value-constrained rules (retention days, RPO/RTO, reviewer count): the engine checks the customer's config value.
- Disjoint-role rules (SoD, code-review reviewer-cannot-be-author): the engine records the declaration; the actual disjoint-role enforcement happens at the platform layer (GitHub branch protection, deployment approvers) — ArchRails surfaces a finding when the CALM declaration is missing.
All deterministic — pure function over your CALM JSON, replayable.
Auto-include during bootstrap (coming)
A future release will let archrails bootstrap detect SOX-relevant
repos (by asking, or by detecting GAAP / 10-K / general-ledger
strings) and offer to auto-include this template. Until that ships,
copy-paste.
Versioning
This is sox-itgc/v0.1.0-beta. Pre-1.0 = beta. Bumps:
v0.x.y-beta— additive / breaking changes are both possible during beta; pinning a beta version is supported but the next beta bump may require authoring updates (documented in the changelog).v1.0.0— graduation to GA per the criteria above.
Updates as authoritative interpretations (PCAOB staff guidance, SEC bulletins, COSO revisions) materially shift the architectural expectations. The constraint engine evaluates every version identically — beta versus GA is metadata, not behavior.
Out of scope for this template
- Process controls (approval workflows, periodic access reviews, segregation-of-duties matrix maintenance, ITGC walkthroughs): document these in your SOX framework, not your CALM.
- Application controls (the in-app financial logic that drives what gets posted to the GL): out of architectural scope; these are your auditor's "automated application controls" testing.
- External-auditor coordination: ArchRails doesn't manage your PCAOB-registered auditor relationship.
For those surfaces, pair this template with your SOX program documentation and your external auditor's expectations.