// ITGC Audit Project
Meridian Financial Services Inc.
Mid-size fintech, $2B annual transactions, preparing for first SOX audit ahead of IPO. You are the IT Audit Associate. Assess ITGCs across 6 key domains. 320 users, 15 privileged admins, bi-weekly DevOps releases.
1Understand Scope
2Plan Testing
3Request Evidence
4Test Controls
5Document Results
6Draft Findings
1. Access Provisioning Review — sample 25 from 320 users (PBC-001)
Verify each sampled account has an approved ticket predating access creation, manager authorization, and appropriate role. Cross-reference PBC-002 for any terminated users still active.
2. Privileged Access Management — test all 18 privileged accounts (PBC-003)
Verify: MFA, PAM enrollment, activity logging, no shared accounts, service accounts have no interactive login, business justification documented.
3. Access Recertification — review all 4 quarterly records (PBC-004)
Confirm manager (not IT) certified access. Check completion dates vs due dates. Verify revocations were made and documented. Flag rubber-stamp reviews.
4. Password Policy — test all systems against policy (PBC-005)
Min 12 chars, complexity, 90-day expiry, lockout after 5 attempts, last 12 passwords. Check system-level configs — policy documents don't count, system enforcement does.
5. SoD Conflict Analysis — review PBC-001 for incompatible roles
Look for: create AND approve payments, developer in production, user admin who can transact, record AND reconcile. Build SoD matrix. Document conflicts and compensating controls.
6. Change Management — stratified sample of 312 tickets (PBC-006)
13 Normal + 7 Standard + ALL 35 Emergency. For each: approval before deploy, test evidence, backout plan, PIR. Emergency: retrospective review within 5 business days.
7. Logical Access to Production — verify no developer write access
Check production access list — only ops/release roles. Test CI/CD pipeline enforces mandatory approvals. Validate any temporary dev access was time-limited and revoked.
8. Backup Controls — 90-day logs + 4 restore test reports (PBC-007 · PBC-008)
Schedule adherence, failure monitoring, off-site storage, quarterly restore tests with independent observers. Check for failures that were alerted but not investigated.
Raw Data (320)
🔍 Exception Hints
PBC-001User Access Listing — SAP + AWS IAM
⚠️
Sample 25 users randomly. Test each: ticket predates access, manager approved, role matches request. Cross-reference PBC-002 for terminated users.
320 records
| # | User ID | Name | Dept | Title | System | Role | Status | Created | Last Login | Request # | Mgr Approved | Notes |
|---|
🔍 What to look for — User Access List
Segregation of Duties — Look for roles that combine incompatible functions. In financial systems, creating and approving the same transaction type in one role is a classic SoD violation.
Terminated users — Cross-reference Status and Last Login. Active users with old last login dates may have been terminated without access revocation. Check if any names cross-reference with your termination list (PBC-002).
Provisioning sequence — The Request date should always precede the Created date. Any reversal means access was granted before it was formally approved.
Dormant accounts — Calculate days since last login. Accounts inactive for 90+ days with no business justification are a standing access risk.
Production access for developers — Look at departments vs system roles. Development staff should not have write access to production systems (SAP Production, SE38).
Approval integrity — The Manager Approved column should never match the user's own name. Self-approved access requests bypass the control entirely.
No expiry date — Contractor and vendor accounts should have defined expiry dates. Missing expiry = indefinite access with no review trigger.
Terminations (47)
🔍 Exception Hints
PBC-002HR Termination Report — Full Year
| # | Emp ID | Name | Dept | Title | Term Date | Type | Systems | IT Ticket | Revoked Date | Days to Revoke | Within SLA? | IT Action By |
|---|
🔍 What to look for — Termination Records
Revocation timeline — Compare Termination Date to Access Revoked Date. Policy typically requires same-day or next-business-day. Calculate the gap in days for each record.
Missing IT tickets — Every termination should have a corresponding IT ticket to trigger access revocation. A blank IT Ticket field means the de-provisioning process was never formally initiated.
Involuntary terminations — These carry heightened risk. Some organisations require immediate (same-day) revocation for involuntary exits regardless of normal SLAs. Check termination type.
Cross-referencing — Compare names in PBC-002 against PBC-001 active users. A terminated employee still showing as Active in PBC-001 means the control failed end-to-end.
Blank revocation dates — A missing Access Revoked date likely means access was never formally revoked. Treat as open until confirmed otherwise.
Privileged Accounts (18)
🔍 Exception Hints
PBC-003Privileged Account Inventory
| # | Account | Name | Type | System | Level | Owner | Justification | MFA | PAM | Logging | Interactive Login | Last Pwd Change | Last Reviewed |
|---|
🔍 What to look for — Privileged Accounts
Service account interactive login — Service accounts should authenticate programmatically only. If Interactive Login = Yes, a human can log in with those credentials — a significant privilege escalation risk.
Shared accounts — Look at the Owner field. Any account owned by a team name rather than an individual person cannot be attributed to a specific user. Non-repudiation fails.
MFA on highest-privilege accounts — Root accounts (AWS, Azure) and admin accounts must have MFA. No exceptions. Check MFA column for critical system accounts.
Password age — Calculate days since last password change. Policy typically requires 90-day rotation for privileged accounts. Accounts with passwords hundreds of days old are out of policy.
Business justification — Every privileged account should have a documented reason it exists and who approved it. Missing or vague justification is itself a finding.
Review frequency — Check the Last Review date. Privileged accounts should be reviewed quarterly. Gaps of 12+ months indicate the oversight process is broken.
Access Reviews (4 Qtrs)
🔍 Exception Hints
PBC-004Quarterly Access Recertification Records
| # | Period | Due Date | Completed | Days Late | Scope | Certifier | Certifier Role | Revocations | Evidence | Method | Issues |
|---|
🔍 What to look for — Access Reviews
Timeliness — Each quarterly review has a scheduled completion date. Calculate how many days late each review was completed. Even one day late means access went unchecked beyond the control period.
Certifier appropriateness — Who certified the access? Policy typically requires business managers — the people who know what access their team actually needs. IT certifying on behalf of business is a segregation failure.
Revocation rate — If zero access was revoked across hundreds of certifications, that is statistically implausible. It suggests the review was rubber-stamped without genuine scrutiny.
Evidence quality — What evidence was retained? "Verbal confirmation" or missing supporting documentation means the control cannot be relied upon even if the outcome was correct.
Password Policy Config
🔍 Exception Hints
PBC-005Password Policy — All In-Scope Systems
⚠️
Required: Min 12 chars · Complexity · 90-day expiry · Lockout after 5 · Last 12 passwords · MFA for privileged users.
| # | System | Min Length | Complexity | Expiry (Days) | Lockout After | Lockout Duration | Pwd History | MFA | Meets Policy | Gap |
|---|
🔍 What to look for — Password Policy
Minimum length — Compare each system's configured minimum against the corporate policy requirement. Any system below the policy threshold is non-compliant.
Password expiry — Look for systems configured with "Never expires." Unless there is an approved exception with compensating controls (e.g., MFA required), indefinite passwords are a policy violation.
MFA enforcement — Systems handling sensitive data (financial, personal data, production) should enforce MFA. A system with MFA = No is a gap, especially if it also has weak password settings.
Account lockout — How many failed attempts trigger a lockout? A high threshold (e.g., 50 attempts) effectively defeats the brute-force protection the control is meant to provide.
Cumulative weakness — A system with short passwords AND no expiry AND no MFA has three concurrent failures. That combination warrants a Critical rating.
Change Tickets (312)
🔍 Exception Hints
PBC-006ServiceNow Change Ticket Export — Full Year
312 records
| # | Ticket | Type | System | Description | By | Approval | Deploy | Pre-Approved? | Test Evidence | Backout Plan | PIR Done | Emergency Retro | Notes |
|---|
🔍 What to look for — Change Management
Approval sequence — The Approved Date must always precede the Deployed Date. Any change deployed before it was approved bypassed the control entirely. Check every record.
Emergency change retrospective reviews — Emergency changes are approved post-deployment, but a retrospective review must be completed within a defined window (typically 5 business days). Check the gap between deployment and review date.
Test evidence quality — "N/A" or "low risk" as test evidence without a formal risk waiver is not acceptable. Every production change requires documented testing unless a waiver exists.
Emergency change rate — Calculate the proportion of changes classified as Emergency. Rates above 5–10% suggest the emergency category is being misused to bypass normal controls.
Blank required fields — A blank Approver, blank Test Evidence, or blank Review Date on a deployed change is an exception regardless of other circumstances.
Backup Logs (90 Days)
🔍 Exception Hints
PBC-007Backup Job Completion Logs — 90 Days
| # | System | Type | Schedule | Total | Success | Failed | Fail % | Alert Sent | Investigated | Storage | Off-Site | Retention | Meets Policy |
|---|
🔍 What to look for — Backup Logs
Failure rate — Calculate each system's backup failure rate over the period. Even occasional failures should be investigated. Repeated failures with no documented investigation are a control failure, not just a technical issue.
Off-site / geographically separate storage — Check where backups are stored. Backups on the same physical infrastructure as production do not protect against site-level failures. Look for "local" storage configurations.
Backup method vs RPO — Compare the backup frequency (daily tape, hourly snapshot) against the system's stated RPO. If a system needs 1-hour RPO but only backs up daily, the maximum data loss could be 24 hours.
Alert response — If failures generated alerts, was there documented investigation and resolution? An alert with no follow-up means the monitoring control is present but the response control is absent.
Restore Tests (4)
🔍 Exception Hints
PBC-008Quarterly Backup Restore Test Results
| # | Quarter | Date | Systems | Backup Used | Actual (hrs) | Target RTO | Met RTO | Data OK | Observer | Result | Issues | Remediated | Approved By |
|---|
🔍 What to look for — Restore Test Reports
Actual vs target RTO — Every test report states the RTO target. Compare against actual recovery time achieved. A system that took longer than its target RTO failed the test — regardless of how it was declared.
Pass/fail declaration vs evidence — The declared result (PASS/FAIL) should match the data. If actual time exceeded the target but the result says PASS, the test declaration is incorrect.
Independent observation — Who observed the test? Self-review by the team running the test has no audit value. Look for independent observer or "None" in the observer field.
Systems never tested — Check whether all critical systems have a corresponding test. A system with no test history has an assumed RTO — which is not a tested RTO.
Remediation after failure — If a prior test failed, was there a documented remediation plan before the next test? Failing without remediation and testing again without fixing anything is a governance failure.
COSO 2013
Control environment, risk assessment, control activities, monitoring. Primary framework for SOX ICFR assessments. All ITGC work feeds into COSO's Control Activities component.
COBIT 2019
DSS06 (Business Process Controls), APO01 (IT Framework), BAI06 (IT Changes). Maps IT controls to business objectives. Use COBIT as the "why" for each ITGC domain.
SOX Section 302/404
Section 404 requires management + external auditors to assess ICFR. ITGCs directly support ICFR — weak ITGCs force auditors to expand substantive testing, increasing costs.
ISO/IEC 27001
Annex A.9 (Access Control), A.12 (Operations Security) align directly to ITGC domains. Use alongside SOX for organizations pursuing both compliance objectives.
CIS Controls v8
Control 5 (Account Management), Control 6 (Access Control Management). CIS Benchmarks provide specific system-level configuration baselines for password and access policy testing.
NIST SP 800-53
AC (Access Control), AU (Audit & Accountability), CM (Configuration Management) families. Technical baselines for ITGC control requirements. Reference specific control IDs in findings.
// Company Policy Document
Meridian Financial Services Inc.
IT General Controls Policy v3.1 · March 2024 · Ref: MFSI-IT-GC-POL-001
💡 Reference specific sections in your CCCEE Criteria — e.g. "Per Meridian IT General Controls Policy v3.1, §2.2..."
§2.2 User Termination
IT Operations must disable all in-scope system access within 48 hours of the termination effective date. HR notifies IT via the IT Service Desk. Notification must be submitted no later than close of business on the termination date.
§2.3 Access Reviews
Semi-annual review of all user access. Privileged access reviewed quarterly. Results documented and retained for minimum 2 years.
§2.4 Segregation of Duties
No single user may both initiate and approve financial transactions above $10,000. SoD conflict matrix reviewed annually.
§3.2 Change Approval
Normal changes require CAB approval. Emergency changes require verbal approval from Head of IT Ops or CTO; written retrospective within 5 business days.
§4.2 Restore Testing
Restore tests conducted annually. Results documented and retained for 2 years.
§5 Privileged Access
MFA is recommended for all privileged accounts. Privileged activity must be logged. Shared accounts are discouraged.
✍️
Use CCCEE: Condition · Criteria · Cause · Effect · Recommendation. Every element is mandatory. Cite specific record counts, dates, and framework clauses.
FINDING-ITGC-001
Document Your Finding
