The platform

From the client’s population to a signed binder, one control at a time.

Each control runs one enforced workflow. The platform performs the data procedures and records them; the auditor judges, concludes and signs.

The workflow

One enforced workflow per control

Scoping: The engagement scopes the systems it covers and the controls it tests, and an Operations control also records which of those systems it runs on. A recommended control the engagement does not test is recorded as excluded or as not covered, and § 4 of the binder prints its justification. Each control can record the entity’s own reference for it, the control as the entity describes it, and its owner at the entity.
Population: Who extracted the population and when, its as-of date, and its columns mapped to the fields the control’s template declares; for a listing of events, the rows dated inside and outside the engagement period are counted. The platform then ties the population, row by row and field by field, to an independent source file the auditor chooses, and lists every row missing from either side and every field that differs; a population that ties in full records that source as its reconciliation. For a periodic control, the platform reconciles the occurrences each period should contain to those listed, and names each missing period.
Sampling: Sizes are recommended from the control’s frequency and risk, and each draw records the basis that sized it; a sample smaller than the recommendation records the auditor’s reason. Random, systematic and stratified draws are made from a recorded seed and can be re-drawn; a judgmental selection records its basis. A stratum can be tested in full and the rest of the population sampled, and a sample can be extended with a further draw, with the reason stated. A user access review and a privileged access review are tested in two stages by default. First the reviews held in the period, sized on the control’s frequency: each review counts in the one interval of that frequency its first certification falls in, and a review the period expects and the population lacks counts as a deviation unless the auditor records why at the draw. What is judged on a review as a whole, such as its timeliness and its reviewer, is recorded once for that review; for a privileged access review that includes its coverage of every account-and-privilege pair on the system’s own listing. Then, within each selected review, the reviewer’s decisions are re-performed on a sample of its lines, and follow-through is tested on the lines it marked for action: all of them, up to the size of that sample. The per-user design remains available, with the auditor’s reason recorded on the run.
Expectations / Traceability: The criterion each attribute is tested against is printed in the binder. The auditor can tailor any attribute’s criterion to the client’s policy, under a stated reason, until work is recorded against it. A criterion the template left open can be tailored after AI verdicts are recorded against it: each verdict stays in the result’s history under the criterion it was tested against, and its sample is marked for a re-run. For Change controls, each sampled change is recorded as a chain of 5 steps (ticket, approval, testing, deployment, closure), a step counts only with its reference and time, and steps recorded out of order are reported as a deviation.
Evidence: Mapped to each sample and attribute. Its source can be recorded as client-provided, auditor-obtained, system-generated or third-party, with a note on where it came from, and the binder prints both. A scanned PDF beyond the per-request page or size cap is read in page ranges. Hashing and re-verification: how the file is defended.
Testing: Each attribute is tested on the sample, by the auditor or by AI under the auditor’s disposition. AI testing runs only on a sample with mapped evidence; an attribute with none mapped to it on that sample is recorded inconclusive without calling the model, and a file name in a rationale that no mapped evidence corroborates is flagged. Wherever the document’s text can be searched, an extracted fact is marked located or not located in it and, where linked, opens its document, at its page when one is recorded. The platform records the auditor’s acceptance, an override with its note, or the auditor’s own result for the attribute. Bulk acceptance is not offered on the Testing step: every AI answer is decided by the auditor, one at a time. Results accepted in bulk under an earlier release stay marked as accepted in bulk and not individually reviewed, and the review signature acknowledges those never opened individually. Where an attribute is a rule over the population’s own columns — closed within so many business days of failing, by priority, for example — it can instead be tested on every row, against the engagement’s calendar of weekends and recorded holidays, and that result stands as the attribute’s test. A test of every row cannot be extended, so a deviation it finds is evaluated as a deficiency, and the control is not concluded effective. The limits on the AI: the model proposes, the auditor decides.
Exceptions: Each exception records a severity and a condition. One raised from an AI result starts with a default severity the platform assigns, and the auditor can revise it; lowering a severity needs a stated reason. A difference a data procedure finds is raised as an exception linked to the run that found it, explained with a reason, or recorded as a scope limitation; the control is not signed off until each is dispositioned.
Quality review: 36 control-level checks, among them consistent treatment of findings and a criterion stated once, and 45 per-sample check types across the library, each reading its column by the role the template declares.
Review: A written conclusion and the gates below, then a review signature from a user account other than the one that signed off, or a single-auditor declaration with its reason. A control found not effective is evaluated as a deficiency, a significant deficiency or a material weakness, with the auditor’s answer on the automated controls and reports that depend on it; where the auditor classifies it differently from the platform’s computed classification, the reason is recorded and the binder prints both. A deviation in a sample is answered one of two ways. Either the sample is extended to the size the platform computes for the deviations found, no further deviation turns up among the added items, and the auditor records why the deviation is not a deficiency; or the deviation is evaluated as a deficiency and the control is not effective. A statistical sample whose projected deviation limit stays within the tolerable rate needs no extension, and the reason is still recorded. A deviation found on every row, a missing access review counted as a deviation, or a failed follow-through line cannot be answered by extending: it is evaluated. Who may sign, and what else the platform refuses: the refusals, one by one.

The gates a reviewer would check run before sign-off, not after it.

The file cites the standards of the framework its engagement is conducted under.

GATE 01Every attribute of every sample tested
GATE 02No AI determination without a recorded acceptance or override; a rejected result overridden, replaced by the auditor’s own result, or re-tested; on an attribute a rule test covers over the whole population, an unreviewed or rejected result set aside with the rule’s result standing
GATE 03No PASS without mapped evidence
GATE 04The population’s completeness established
GATE 05Where each cited evidence file came from, and when it was prepared, recorded
GATE 06An effective conclusion refused where the sample evaluation does not support it

Show all 23 gates (the lock's 28 hard blockers, in 20 lines, and the conclusion's 3)

GATE 07Conclusion selected and a written narrative of substance
GATE 08Deficiency evaluated where the control is not effective
GATE 09Deviations under an effective conclusion judged: evaluated as a deficiency, or stated with a reason not to be one
GATE 10A deviation judged not a deficiency rests on a sample extended to the size the platform computes for the deviations found, with no further deviation among the added items, unless a statistical sample’s projected deviation limit stays within the tolerable rate; otherwise it is evaluated as a deficiency
GATE 11Quality review run; its critical, high and medium findings acknowledged
GATE 12Exceptions closed, accepted, or carried to the deficiency evaluation (Evaluated), and the exceptions review confirmed
GATE 13Every failed test result, the auditor’s own or a reviewed AI result, recorded as an exception against its attribute, or against the item as a whole, whatever the conclusion
GATE 14No critical or high exception outstanding past the resolution period for its severity
GATE 15Change-control traceability complete
GATE 16In a two-stage sample, an attribute judged on a selected review as a whole carries one result for that review, not different results on its lines
GATE 17A sample tested short of its drawn size only with replacement items or a recorded reason
GATE 18An accepted AI result that needs a reviewer’s item-specific note carries one
GATE 19No effective conclusion over an inconclusive sample left unresolved
GATE 20A scope limitation judged a deficiency carries its deficiency evaluation
GATE 21No deficiency lowered by reliance on a control the same file concludes is not effective
GATE 22Deviations a whole-population rule test finds, and missing occurrences recorded as a scope limitation, carry a deficiency evaluation, and the control is then not concluded effective
GATE 23Every difference a data procedure finds dispositioned: explained with a reason, raised as an exception, or recorded as a scope limitation

Sign-off is locked until every gate passes

The auditor is the authoritative gate. The lock holds 28 hard blockers, and the conclusion adds the sample evaluation, the narrative and the deficiency evaluation; warnings are kept apart and do not stop a sign-off.

The data procedures

Data procedures the platform performs

The procedures a reviewer would otherwise re-perform by hand in a spreadsheet run on the platform. Each is stored as a run with the fingerprints of what it read, the version of the code that performed it and who ran it, and the binder prints the run. Every difference a procedure finds is stored and listed, and each is dispositioned before the control is signed off: explained with a reason, raised as an exception, or recorded as a scope limitation. A procedure run over a population that a newer upload has replaced is refused, and nothing is recorded. A procedure reads each source file on the server, never through the model, and only when its stored bytes match the SHA-256 recorded at upload. A file it cannot read whole — over its size or row limits, malformed, or a workbook whose structure and declared sizes fail the checks made before any part of it is expanded — is refused, never read in part.

Population completeness and accuracy: The population agrees, row by row and field by field, with an independent source the auditor chooses. Every row missing from either side and every field that differs is listed, and a population that ties in full records that source as its reconciliation.
Occurrence reconciliation: A periodic control ran in every period of the tested window, for every instance it covers, and each missing period is named.
Whole-population rule test: A rule the auditor defines holds on every row of the population — for a timeliness rule, measured in business days on the engagement’s own calendar of weekends and recorded holidays. The result stands as the attribute’s test, with every exception listed.
Stratum tested in full: Every item in a stratum the auditor chooses is tested, and the rest of the population is sampled. A deviation in the full stratum is a known deviation; only the sampled remainder is projected.
Cross-population ties: Related populations and files agree in both directions — for example, accounts created to the access they were granted, or changes in a system's log to their tickets. Rows that do not tie are listed on each side.
Segregation-of-duties reperformance: The client’s conflict rules, applied to its role listings, find the conflicts the client’s own analysis reported, period by period. A conflict the analysis did not report, or reported in error, is listed.
Configuration reperformance: A listing of settings agrees, setting by setting, with the values read from the systems’ own extracts, and the state a listing reports agrees with the systems’ own health reports. Each disagreement is listed.

The platform runs the procedure. Whether an exception it lists is a deviation, and what it means for the control, is the auditor’s judgment.

Scope

What the platform covers, and what stays with the firm’s methodology

Covers

Operating-effectiveness testing of IT general controls across access, change, operations and security, from the client’s population to the finalized binder: the data procedures above; deficiency evaluation for a control found not effective, alone and in combination with others; and interim and roll-forward work.

Stays with the firm’s methodology

Design and implementation work, reliance on service-organization reports, and how an ITGC deficiency affects the application controls and reports that depend on it. The platform does not perform these; where the deficiency evaluation asks about dependent controls and reports, it records the auditor’s answer.

Limits. A population holds up to 10,000 rows, and a sample up to 500 items drawn from it; a source file a data procedure reads holds up to 200,000 rows.

The binder and the package

What the file carries: the binder and the archive package

The export is one self-contained HTML binder. An index rail with search leads to a chapter per control that opens on its conclusion, with Results, Provenance, Evidence and Exceptions one tab away and a working-paper reference on every chapter. Its headings are real headings, it prints a chapter or the whole binder, it reads complete with scripting off, and its cover carries a SHA-256 computed over the document with that value replaced by a placeholder. Two CSV files are exported beside it: the evidence index, with every file’s SHA-256, and the testing results.

The archive package adds what the binder points at: every sampled population as drawn, with the selected rows marked, and each draw’s selected indices and, for a seeded draw, its seed; the engagement’s audit trail, with a companion chain file holding the fields each row’s hash is computed over, so the chain can be recomputed; the evidence files, named to the index, with any file the package leaves out listed in its manifest with the reason; a manifest of every entry’s SHA-256; and a README.

What the binder prints, and where

AI ⇄ AUD: The AI’s determination beside the auditor’s disposition, never blended into one value.; § 7
EVIDENCE: The name and SHA-256 of each evidence file behind the test.; § 7 · § 13
TIMESTAMPS: When the test ran, and when and by whom it was accepted or overridden.; § 7
FACTS: The facts extracted from the evidence, each with its file and, where recorded, its page, beside the rationale.; § 7
ENTITY: The entity’s own reference for each control, or a line saying that none is recorded, and in the control’s chapter the control in the entity’s words and its owner where they are recorded.; § 5 · § 7
SAMPLING: The seed, the algorithm version, and the population’s row count and SHA-256 at the draw.; § 6
PROCEDURES: Each data procedure run on the population: its sources and their fingerprints, the counts, every exception, who ran it and when.; § 6
DEFICIENCY: For a control concluded not effective, the deficiency evaluation behind the conclusion, with the auditor’s classification and the computed one where they differ.; § 10
VERSIONS: Earlier versions of an AI result, each with the action and the user account that superseded it.; § 7
REVIEW: The preparer’s sign-off and the review signature or declaration, on the cover and each chapter.; § 1 · § 7

The binder’s sections

01: Cover Sheet & Sign-Off
02: Executive Summary
03: Scope & Systems
04: Scope Gap Justifications
05: Controls Matrix
06: Population & Sampling Documentation
07: Testing Results by Control

08: Traceability (Change Controls)
09: Exception Summary
10: Deficiency Evaluation
11: Quality Review Summary
12: Audit Trail
13: Evidence Index
14: Abbreviations & Glossary

The control library

37 ITGC control templates in 4 categories

Each template declares its population schema, its test attributes, the evidence it expects and its quality rules, with SOX 404, COSO and SOC 2 mapping fields that are documented mappings, not certifications. The templates are a starting point: in customization they are mapped to the firm’s own ITGC domains and control descriptions.

Every template’s COSO 2013 mapping was reviewed against one boundary. A control that acts on what the risk is about — access rights, changes, jobs, incidents, logged events — is a control activity. Monitoring, the entity’s evaluation of its own internal control, appears only as a secondary mapping, where a control’s results also show whether another control operated. Every template carries the reason for its mapping beside it in the catalogue, and the binder prints the mapping of the template version each control was tested under.

Access: User Provisioning Approvals · User Terminations Timeliness · Privileged Access Grant & Justification · Privileged Access Periodic Review · Break-Glass Emergency Access · User Access Reviews (UAR) · Service Accounts Lifecycle · Authentication Controls · Cloud IAM Policy and Identity Review · MFA Enrollment and Resilience · Third-Party / Sub-processor Risk Review; 11
Change: Normal Change Approvals · Emergency Changes · Release Controls · CI/CD Pipeline Controls · Configuration/IaC Changes · System Development and Acquisition Approval · Pre-Implementation Testing and UAT Sign-Off · Post-Implementation Review · Data Migration and Conversion Controls; 9
Operations: Backup Success Monitoring · Restore Testing · Batch Job Monitoring · Monitoring & Alert Response · Incident Management · Problem Management · Patch Management · Logging & Audit Log Review · DR/BCP Testing · Backup Immutability and Ransomware Readiness · Interface and Data-Transfer Monitoring; 11
Security: Security Event Logging · Segregation of Duties · Vulnerability Management · Access Review Authorization · Encryption Key Management · AI-Governance Controls; 6

A practitioner’s question?

Write with a question about the workflow, the binder or the library.

Ask a question How the file is defended