Case studies / ITGC audit
Simulated case study: fictional company (Northstar Financial Technologies), synthetic data, no real audit or client.
1. Risk-based IT general controls audit
16 tests over 15 of 33 controls produced 14 findings (6 High, 7 Medium, 1 Low). The headline is leaver access: 8 of 35 leaver accounts (22.9%) were not removed in time, and one of them logged in 6 days after the employee left.
Why it matters to the business
The business context. Northstar, the fictional company, moves money for business customers. Its most important service, Business Payment Acceptance, is rated Critical, handles Restricted data and must recover within 4 hours with at most 1 hour of data loss. It depends on the Payments API, the Core Ledger and the AWS production account, three of the 5 systems in scope. Customers of a payments company are trusting its access and change controls without ever seeing them. This audit looks at those controls from the inside.
What is at stake. The risk register scores “Inappropriate or unremoved user access” (R-01: 20 out of 25 before controls, recorded residual 12), the highest of its 14 risks. Management's recorded residual score of 12 puts it in the band where the risk owner can accept it. The audit asks whether the controls behind that number really work. If a former employee's administrator account can still reach payment data, the recorded score is optimistic and the business is carrying more risk than it believes. Northstar's stated appetite is low for unauthorised access to Restricted data, and confirmed access after termination must be escalated to the Chief Risk Officer.
Who relies on the work. The Chief Risk Officer sponsors the audit and the Audit Committee receives the report. The IT Security Manager, Head of IT Operations, Head of Platform Engineering and Change Manager own the fixes. The Controller depends on the ledger's integrity. Each needs something different: assurance, a prioritised list of fixes, a date, and evidence that a customer or regulator would accept.
What the business needs from this work.
- An honest answer about which controls work, backed by evidence, not a list of items marked passed.
- Findings an owner can act on (what was found, what it was compared with, why it happened, why it matters, what to do) and a retest showing whether the fix held.
- Clear limits, so that none of the 18 controls that were not tested is read as clean.
What this shows about how I work. It turns a control statement into a testable rule, proves a population is complete before relying on it, separates real exceptions from look-alikes, and refuses to count a fix that fails retest. Those are the habits that IT audit and GRC job postings ask for.
Scope and assumptions
- Systems SYS-01 to SYS-05 (portal, payments API, core ledger, CI/CD, AWS production). Period 2026-01-01 to 2026-06-30; fieldwork 2026-07-13 to 2026-08-28; extracts dated 2026-07-15.
- Criteria are the fictional policy parameters in one file (for example 2 business days for leaver removal, 90 days dormancy). They are invented for this exercise.
- Independence: the audit team is fictionally independent of the systems audited (stated in the planning memo).
- Out of scope: other systems, physical security and application business logic.
Approach
I rated 14 enterprise risks, mapped them to 33 controls and selected 15 for testing on risk, leaving 18 not tested with the reason recorded for each. For every test the population was completed first (does the extract agree to the source?), and the rule was then applied by script to every record rather than a sample, because the evidence was a complete system export. Exceptions were separated from near-misses that look odd but comply with the stated rule, and the near-misses were not reported. Tolerable deviation was 0% for leaver, privileged, developer-segregation and service-account-owner controls and 5% elsewhere.
Every finding states condition, criteria, cause, consequence and recommendation, and links to the test, the evidence and the exception records.
What is automated, and what is not
Automation here means scripts that run the same way every time on synthetic data. It is not a live connection to any real system. The table separates what a script does from what still needs judgement.
| What is automated | How | Where in the repository | What a person still does |
|---|---|---|---|
| All 16 control tests | Each rule is code that checks every record in the population, so there is no sampling error | scripts/itgc_audit.py, itgc_config.py | Choosing which controls to test and why, and deciding what counts as an exception |
| Exceptions versus near-misses | Boundary cases (for example, disabled on the last allowed day) are written into the rule and tested | scripts/itgc_audit.py | Judging unusual cases the rule did not anticipate |
| Workpapers, findings and reports | 16 workpapers, 14 findings, four PDF reports and two workbooks are generated from the test results | scripts/itgc_findings.py, generate_p1_reports.py, generate_p1_pdfs.py | Assessing cause, consequence and the recommendation, and the wording of the report |
| Retest | The same tests are re-run on new data and compared with the earlier result | scripts/itgc_audit.py, data/analysis/retest_evidence.csv | Deciding whether a fix really worked and following up with management |
| Daily monitoring (demo) | Three of the tests are re-run every day over a 31-day simulated feed | src/ccm/ | Triaging alerts and deciding what to escalate |
Re-run it. bash scripts/build_all.sh rebuilds everything from the synthetic data in 22 steps and runs 92 automated tests. The single script is named in each row.
See the continuous monitoring demo and the automation overview.
Results
12 of 16 tests concluded not operating effectively, 3 operating effectively with exceptions within tolerance, and 1 was inconclusive (backup restoration, where the completeness of the restore register could not be confirmed). Four tests also recorded a design deficiency. No test concluded with zero exceptions.
Because controls were selected by risk, these results do not describe the whole environment.
| T-01 | NS-IAM-01 | 408 | 5 | Operating effectively with exceptions (within tolerance) | Workpaper |
|---|---|---|---|---|---|
| T-02 | NS-IAM-02 | 35 | 8 | Not operating effectively | Workpaper |
| T-03 | NS-IAM-03 | 13 | 2 | Not operating effectively | Workpaper |
| T-04 | NS-IAM-04 | 10 | 8 | Not operating effectively; design deficiency noted | Workpaper |
| T-05 | NS-IAM-05 | 14 | 4 | Not operating effectively; design deficiency noted | Workpaper |
| T-06 | NS-IAM-06 | 396 | 4 | Operating effectively with exceptions (within tolerance) | Workpaper |
| T-07 | NS-IAM-07 | 413 | 3 | Not operating effectively | Workpaper |
| T-08 | NS-PAM-01 | 19 | 2 | Not operating effectively | Workpaper |
| T-09 | NS-CHG-01 | 77 | 5 | Not operating effectively | Workpaper |
| T-10 | NS-CHG-02 | 77 | 5 | Not operating effectively | Workpaper |
| T-11 | NS-CHG-03 | 91 | 4 | Not operating effectively | Workpaper |
| T-12 | NS-CHG-04 | 14 | 3 | Not operating effectively | Workpaper |
| T-13 | NS-OPS-01 | 727 | 5 | Operating effectively with exceptions (within tolerance) | Workpaper |
| T-14 | NS-OPS-02 | 8 | 3 | Inconclusive; design deficiency noted | Workpaper |
| T-15 | NS-OPS-02 | 5 | 2 | Not operating effectively | Workpaper |
| T-16 | NS-LOG-02 | 25 | 8 | Not operating effectively; design deficiency noted | Workpaper |
No rows match the current filters.
Findings
Each row links to the test workpaper that supports it. F-13 is rated High provisionally: the evidence could not confirm that the restore register was complete, so the conclusion is inconclusive rather than failed.
| F-01 | Terminated employees retained active access to in-scope systems | High | Operating failure | Partially remediated | Retested 2026-09-28: partially remediated | T-02 |
|---|---|---|---|---|---|---|
| F-02 | Administrator access granted without documented approval | High | Operating failure | Remediation in progress | Not yet due | T-08 |
| F-03 | Quarterly user access reviews were late, incomplete, not independent or ineffective | High | Operating failure and design deficiency | Open | Not yet due | T-04 |
| F-04 | Service accounts without a valid owner | Medium | Design deficiency and operating failure | Open | Not yet due | T-05 |
| F-05 | Multi-factor authentication not enabled on some human accounts, including an administrator | High | Operating failure (isolated, but one Admin account) | Closed (retested) | Retested 2026-09-28: remediated | T-07 |
| F-06 | Dormant and role-change access not removed | Medium | Operating failure | Remediation in progress | Dormant accounts retested 2026-09-28: remediated; mover access not yet due | T-06, T-03 |
| F-07 | Some access was granted before approval, or without an approval record | Low | Isolated exceptions | Risk accepted | Not applicable (risk accepted) | T-01 |
| F-08 | Developers deployed their own changes to production | High | Operating failure | Open | Not yet due | T-11 |
| F-09 | Normal changes lacked test evidence, independent approval or prior approval | Medium | Operating failure | Open | Not yet due | T-09, T-10 |
| F-10 | Emergency changes approved retrospectively after the 2-business-day limit | Medium | Operating failure | Open | Not yet due | T-12 |
| F-11 | Failed backups of the Payments API were not re-run | Medium | Operating failure | Open | Not yet due | T-13 |
| F-12 | Restoration tests were not evidenced or not successful, and the control has no minimum frequency | Medium | Design deficiency and operating failure (evidence) | Open | Not yet due | T-15, T-14 |
| F-13 | No restoration test recorded for the Core Ledger or Data Warehouse (inconclusive pending confirmation) | High | Evidence insufficiency (not a confirmed control failure) | Inconclusive: awaiting management confirmation | Not yet due | T-14 |
| F-14 | Weekly security alert reviews were missing, late, duplicated or lacked escalation | Medium | Operating failure and design deficiency | Open | Not yet due | T-16 |
No rows match the current filters.
Remediation and retest
On 2026-09-28 (simulated) I re-examined the same populations. Management reported three containment actions complete. Two passed (multi-factor authentication, and dormant and role-change access). The third, disabling the four remaining leaver accounts, did not pass: account A-0329 was still Active 227 days after termination. The dashboard therefore counts that action as not complete, even though management reported it done.
What management should do
- Disable the remaining leaver accounts now and establish who used account A-0132 (a Payments Console Admin account that logged in 6 days after the employee's termination). Under the fictional appetite statement, confirmed post-termination access escalates to the Chief Risk Officer.
- Automate deprovisioning from the HR feed and reconcile terminations to active accounts daily.
- Require a ticket reference before an Admin role can be assigned.
Uncertainty and limitations
- The HR termination list supplied was partial, so further leaver exceptions may exist.
- Approval tickets were checked for existence, not content; the ticketing system itself was not inspected.
- Accounts created and deleted inside the period are not in the extract.
- All records are synthetic. Seeded issues were designed in, so detection here shows the method works, not how common such failures are.
Downloads
Every file below is generated by this repository's scripts and listed in the download index.
- Audit planning memoPDF · 15 KB
- Draft management report (2026-09-04)PDF · 28 KB
- Final audit report (2026-09-18)PDF · 32 KB
- Retest results (2026-09-28)PDF · 8 KB
- Audit program and risk-control matrixXLSX · 23 KB
- Finding registerXLSX · 23 KB
- Findings (CSV)CSV · 12 KB
- Control tests (CSV)CSV · 10 KB
- Test exceptions (CSV)CSV · 8 KB
- Remediation actions (CSV)CSV · 3 KB
- Retest evidence (CSV)CSV · 0 KB
Sources
- S001: The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29) (NIST), verified
- S003: NIST AI Risk Management Framework (AI RMF 1.0) landing page (NIST), partially verified
See the full source register.