SOX ITGC OPERATIONAL PACKAGE

Control Library · SOX-Relevant System Register · Evidence Reuse · Deficiency Workflow

Table of Contents

1. Purpose and Scope
2. In-Scope ITGC Domains
3. SOX-Relevant System Register
4. ITGC Control Library
5. Evidence Reuse Mapping
6. SOC 1 Reuse Procedure
7. Deficiency Workflow
8. Auditor Interface
9. Operating Cadence
10. Regulatory and Framework Alignment Summary
11. Document Control

1. Purpose and Scope

SOX shows up in the policy, the compliance matrix, the IT and Access standards, the risk procedure, and the operating model, but until this package, there was no SOX ITGC control library, no SOX-relevant system register, and no auditor-facing deficiency workflow.

This package fills that gap. It assumes the organization is a publicly-traded U.S. company subject to the Sarbanes-Oxley Act with both external auditor and Internal Audit interaction. Where the organization is private, regulated by an analogous regime, or pre-IPO, the structure of this package adapts but the boundaries, scope by financial-reporting impact, evidence reused from operating controls, remain.

The CERG SOX Model in One Sentence

SOX is not a separate control universe, it is a scope filter over the controls CERG already operates, with formal documentation and quarterly testing for the systems that touch financial reporting.

2. In-Scope ITGC Domains

The six ITGC domains in scope are the standard set for a publicly traded company:

If the organization’s audit firm scopes differently (some include “End-User Computing” or “Cybersecurity” as separate categories), CERG aligns to that scoping and updates the library; the six above are the durable spine.

3. SOX-Relevant System Register

The Register is the scope filter, the list of systems whose controls feed external financial reporting. Every CERG control test under SOX scope is performed against systems in this register.

The register is owned jointly by CERG Governance (SOX liaison) and Finance / Internal Audit; CERG owns the cyber slice.

4. ITGC Control Library

Each control names the SOX domain it supports, the CERG control it reuses from CERG-GOV-CB-001, the SOX-specific evidence the auditor expects, and the test approach.

4.1 Access ITGCs

4.2 Change ITGCs

4.3 Operations ITGCs

4.4 Backup ITGCs

4.5 Interfaces ITGCs

4.6 Reports ITGCs

5. Evidence Reuse Mapping

The mapping in Section 4 reuses CERG’s existing evidence library. The principle, repeated:

SOX Reuses CERG Evidence; CERG Does Not Create SOX-Only Tests

If a CERG control test is already running at the cadence the SOX auditor needs, on a system in the SOX register, the SOX test consumes that evidence. CERG does not produce a parallel “SOX-only” version. Where reuse is impossible, e.g., the SOX auditor explicitly requires a different sample period, CERG produces the supplemental sample but documents the reuse principle in the test working paper.

Specifically, the most-reused artifacts:

• Quarterly access recertification reports (AX-03, AX-04, AX-05).
• PAM session logs (AX-05).
• Change management records and CI/CD pipeline configuration (CH-01, CH-02, CH-03, CH-04, RP-01).
• SIEM source inventory and detection coverage report (OP-01, OP-02, OP-03, IF-03).
• Backup tool reports and restoration test evidence (BK-01, BK-02, BK-03).
• DISH baseline scan output (where SOX-relevant systems’ configuration is tested).

6. SOC 1 Reuse Procedure

CB-001 §10.1 SOX crosswalk and §7.1 Inheritance establish that SOC 1 reports can be reused for hosted financial systems. This procedure operationalises that reuse: it defines how CERG acquires SOC 1 reports, inventories Complementary User Entity Controls (CUECs), performs gap analysis, documents compensating controls, builds an evidence package for the external auditor, and manages the annual refresh cycle.

6.1 Report Acquisition

SOC 1 Type II vs. Type I

CERG accepts SOC 1 Type II (tested over a period) as the primary reuse evidence. SOC 1 Type I (point-in-time design only) is accepted as interim evidence only when a Type II is not yet available, and must be supplemented with customer-side testing of the operating effectiveness of CUECs.

6.2 CUEC Inventory

Complementary User Entity Controls (CUECs) are controls the customer (CERG’s organization) must operate for the SOC 1 controls to be effective. Missing CUECs create control gaps.

CUEC Inventory Table

6.3 Gap Analysis vs. CB-001 Controls

For each SOC 1 control objective that overlaps with a CB-001 control, the gap analysis determines whether CERG’s control is sufficient to cover the provider’s control objective, or whether a gap exists.

The gap analysis is documented in the CB-001 SOX crosswalk (§10.1) and in the SOC 1 evidence package (Section 6.5 below).

6.4 Compensating Controls

Where a gap exists (Partial or No Coverage), compensating controls are designed and implemented.

6.5 Evidence Package for External Auditor

The SOC 1 Reuse Evidence Package is submitted to the external auditor at the start of SOX testing (interim phase). The package contains:

SOC 1 Reuse Summary Memo

A one-to-two-page memo accompanies the package explaining: - Which SOX-relevant systems use SOC 1 reuse - Which ITGC domains are covered by each SOC 1 (per §4 domain mapping) - CUEC status summary (count of implemented / partial / missing) - Gap analysis conclusion (material or immaterial gaps) - Compensating controls in place - Auditor coordination notes (any scope limitations in the SOC 1 report) - Next refresh date

6.6 Annual Refresh Cycle

6.7 Roles and Responsibilities

7. Deficiency Workflow

8. Auditor Interface

9. Operating Cadence

10. Regulatory and Framework Alignment Summary

11. Document Control

Source: plans/CERG-PLN-SOX-001_SOX_ITGC_Operational_Package.md · Download .md · View on GitHub