// 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.

PreventivePBC-001 · PBC-002COBIT DSS06 · SOX

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.

High RiskPBC-003CIS Control 5 · NIST AC-6

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.

DetectivePBC-004SOX · ISO 27001 A.9.2.5

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.

PreventivePBC-005NIST SP 800-63B

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.

High RiskPreventiveCOSO · SOX 302/404

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.

PBC-006COBIT BAI06 · ITIL

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.

High RiskPBC-001SOX · COBIT APO01

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.

CorrectivePBC-007 · PBC-008ISO 27001 A.12.3

Raw Data (320)

🔍 Exception Hints

PBC-001User Access Listing — SAP + AWS IAM320 accounts · Jan 15 export · J. Okonkwo (IT Admin)

⚠️

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 Year47 terminations · Workday HR · L. Mensah (HR)

#	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 Inventory18 accounts · CyberArk PAM + AD · Feb 1

#	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 Records4 quarters · SailPoint IIQ

#	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 SystemsSystem config exports + screenshots

⚠️

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 Year312 changes · Normal 198 · Standard 79 · Emergency 35

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 DaysVeeam + AWS Backup · All critical systems

#	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 Results4 tests · IT Operations · B. Owusu (Cloud Ops)

#	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.

✍️

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

Control Area

Risk Rating

Condition — What did you find? (specific: cite numbers, dates, %)

Criteria — Policy/regulation/framework requirement (cite version + section)

Cause — Root cause (process, people, or technology failure)

Effect — Business / regulatory impact

Recommendation — Specific, actionable, with suggested owner and timeline

Management Action Plan — Proposed response from management

// IT Data Management Project

HealthBridge Corp — GDPR/HIPAA Review

Healthcare analytics company, 2.4M patient records, EU + US operations. No formal data inventory. PHI stored in unmanaged spreadsheets. Recent GDPR inquiry from EU DPA. Your job: find the gaps before regulators do.

🚨

GDPR violations = up to €20M or 4% global turnover. HIPAA violations = up to $1.9M per incident. Every data handling gap you find here could prevent massive regulatory exposure.

1Understand Scope

2Identify Data

3Retention Review

4Privacy & DSAR

5Encryption & Vendors

6Draft Findings

1. Data Inventory & Classification — review 64 assets (DM-001)

Identify unclassified data, assets with no owner, shadow data stores, and assets not reviewed in 12+ months. Cross-reference against IT system register.

DAMA DMBOK · ISO 27001 A.8.2

2. Retention & Disposal — review all data categories (DM-002)

Check company retention periods against legal minimums (HIPAA = 6 years). Flag past-retention data not deleted and categories with no automated deletion.

HIPAA · GDPR Art.5(1)(e) · NIST 800-88

3. Privacy & DSAR Compliance — 18 requests (DM-003)

Verify each DSAR responded within 30-day GDPR clock. Check identity verification before data was provided. Flag any overdue open requests.

GDPR Art.15-17

4. Encryption Configuration — all PHI data stores (DM-004)

AES-256 at rest, TLS 1.2+ in transit. Check for deprecated TLS versions, expired certificates, and missing encryption on PHI systems.

HIPAA Technical Safeguards · NIST 800-53 SC-28

5. Vendor Register — 22 vendors (DM-005)

Every vendor receiving PHI needs a signed BAA. Every vendor processing EU data needs a signed DPA. Check SOC 2 report currency (max 12 months old).

GDPR Art.28 · HIPAA BAA

6. Breach Response Plan — assess all elements (DM-006)

72-hour GDPR clock must be explicit. Check last tabletop date. Verify EU DPA contact list exists. Confirm media communications protocol.

GDPR Art.33/34 · HIPAA Breach Notification

7. Third-Party Risk — review vendor onboarding controls

Beyond BAA/DPA: do vendors undergo security assessments? Is there a formal vendor risk program? What happens when a vendor's SOC 2 expires?

ISO 27001 A.15 · NIST CSF ID.SC

Data Inventory (64)

🔍 Exceptions

DM-001Enterprise Data Inventory64 assets · Data Governance Team · Partial inventory

#	Asset ID	Asset Name	BU	Type	PHI?	Classification	Owner	Storage	Location	Encrypted	Retention	Last Reviewed

🔍 What to look for — Data Inventory

PHI without encryption — Any asset containing PHI (Patient Health Information) must be encrypted at rest and in transit. Look for PHI = Yes combined with Encrypted = No.

Missing data owners — Every asset in the inventory must have a named individual as Data Owner. Team names or blank fields are not acceptable — no individual is accountable.

Classification gaps — PHI or PII data classified as "General" or "Unclassified" is a misclassification. The classification should reflect the highest sensitivity of data contained.

Shadow data / rogue copies — Look for assets stored in unexpected locations (SharePoint personal folders, analyst laptops, local drives) that appear to be copies of regulated datasets.

Retention vs classification alignment — High-sensitivity data should have defined, shorter retention periods. "Indefinite" retention on PHI or PII is typically non-compliant.

Retention Schedule

🔍 Exceptions

DM-002Data Retention Schedule + Deletion EvidenceSource: Legal/Compliance · R. Nwosu (Compliance)

#	Data Category	Legal Req.	Company Period	Meets Legal Min	Auto Delete	Del. Verified	Del. Log	Past Retention?	Volume	Notes

🔍 What to look for — Retention Schedule

Indefinite retention — GDPR Article 5(1)(e) requires data be kept "no longer than necessary." Any category with "Indefinite" retention period is a red flag requiring specific legal justification.

Overdue disposal — Check whether the scheduled disposal date has passed. If yes, has disposal actually occurred? Outstanding disposal past the scheduled date is a live compliance violation.

Legal hold conflicts — Data under legal hold should be flagged and excluded from normal deletion. Unexplained holds, or holds with no review date, may be misused to avoid deletion obligations.

Regulatory minimum vs practice — Some categories have legally mandated minimum retention (e.g., employment records, financial records). Retention periods shorter than the legal minimum are also a finding.

DSAR Tracker (18)

🔍 Exceptions

DM-003Data Subject Access Request Tracker18 requests · DPO Office · GDPR 30-day clock applies

#	DSAR ID	Type	Region	Received	Deadline	Responded	Days	On Time?	ID Verified	Method	Data Provided	Notes

🔍 What to look for — DSAR Tracker

Response time — GDPR requires response within 30 calendar days (extendable to 90 with notification). Calculate days from receipt to response for each DSAR. Any over 30 days without documented extension is non-compliant.

Identity verification — Before responding to a DSAR, the requestor's identity must be verified. Look for DSARs marked as responded but with no verification step documented.

Completeness of response — A partial response (some data provided, some withheld without legal basis) is an incomplete fulfilment. Look for notes indicating partial responses.

Extension notification — If a request took more than 30 days, was the data subject notified within the first 30 days that an extension was being applied? Extending without notification is itself a breach.

Encryption Config

🔍 Exceptions

DM-004Encryption Configuration — All PHI SystemsSSL Labs scan + system configs · T. Obi (InfoSec)

#	System	PHI?	Enc. at Rest	Algorithm	Enc. in Transit	TLS Version	Cert Valid	Key Mgmt	Key Rotation	Meets HIPAA	Gap

🔍 What to look for — Encryption Configuration

No encryption at rest — Any system storing PHI or PII with "No" for At Rest encryption is a direct HIPAA/GDPR violation. Encryption at rest is mandatory for regulated data.

Deprecated protocols — TLS 1.0 and TLS 1.1 are deprecated and vulnerable (POODLE, BEAST attacks). Any system using these for In Transit encryption should be flagged regardless of other controls.

No encryption in transit — Systems transmitting regulated data without In Transit encryption expose data to interception. This is especially critical for APIs and data transfer systems.

Key management — "Manual rotation" or "None" for key management on systems holding regulated data is a weakness. Automated key rotation with defined schedules is the standard.

Last rotation date — Calculate how long ago encryption keys were last rotated. Gaps of 18+ months with no documented exception are out of policy for most frameworks.

Vendor Register (22)

🔍 Exceptions

DM-005Third-Party Vendor Register22 vendors · Procurement + Legal

#	Vendor	Service	PHI?	BAA Signed	BAA Date	DPA Signed	DPA Date	SOC 2	SOC 2 Period	Assessment	Status

🔍 What to look for — Vendor Register

PHI vendors without BAA — Any vendor processing PHI must have a signed Business Associate Agreement (BAA) under HIPAA. PHI = Yes with BAA = No is a direct regulatory violation and a potential breach trigger.

EU data transfers without DPA — Vendors receiving EU personal data must have a signed Data Processing Agreement under GDPR Article 28. Check EU data flag against DPA status.

Stale assurance reports — SOC 2 reports older than 12 months are typically considered expired for audit purposes. Calculate the age of each vendor's most recent assurance report.

No risk rating — Vendors with blank or "TBC" risk ratings have not been formally assessed. This means no informed decision was made about the risk they pose to the organisation.

High-risk vendors with no compensating controls — A vendor rated High or Critical with no listed compensating controls or monitoring is an unmanaged risk.

Breach Response Plan

🔍 Exceptions

DM-006Data Breach Response Plan AssessmentPlan v1.4 · Last updated: 19 months ago · Privacy Team

#	Plan Element	Required By	Present?	Adequate?	Last Updated	Owner	Notes

🔍 What to look for — Breach Response Plan

Regulatory notification timelines — GDPR requires notification within 72 hours of becoming aware of a breach. Any plan element describing notification without a specific clock or trigger is non-compliant.

Plan currency — When was the plan last tested or reviewed? Both HIPAA and GDPR expect regular testing. A tabletop exercise from 2+ years ago does not demonstrate readiness.

Named roles vs vacancies — Key roles in the breach response (Media Spokesperson, DPO, Legal Lead) must be filled by named individuals. Vacant roles or "TBC" mean the plan cannot execute as written.

Template completeness — Notification templates with placeholder text (e.g., [INSERT NAME]) have never been finalised. In a real breach, these would delay notification.

Regulatory contact lists — The plan must include contact details for relevant supervisory authorities (ICO, SEC, etc.). Missing or outdated contacts mean notifications may not reach the right authority.

✍️

Use CCCEE: Condition · Criteria · Cause · Effect · Recommendation. Every element is mandatory. Cite specific record counts, dates, and framework clauses.

FINDING-DM-001

Document Your Finding

Control Area

Risk Rating

Condition — What did you find? (specific: cite numbers, dates, %)

Criteria — Policy/regulation/framework requirement (cite version + section)

Cause — Root cause (process, people, or technology failure)

Effect — Business / regulatory impact

Recommendation — Specific, actionable, with suggested owner and timeline

Management Action Plan — Proposed response from management

// BCP Review Project

Coastal Logistics Ltd — Post-Ransomware BCP Audit

800 staff, 3 warehouses, 6 ports. Ransomware 18 months ago cost $3.2M and 11 days downtime. BCP last updated 3 years ago. New ERP deployed 8 months ago — not in the BIA. Board has mandated a full review.

🚨

BCP without current BIA = fire escape plan that doesn't account for where people are. Start with BC-001 (BIA). Everything else flows from it.

1Understand Scope

2Review BIA

3Review Plans

4Test Programme

5Governance

6Draft Findings

1. BIA Assessment — 18 processes (BC-001)

Check MTD/RTO/RPO populated and logical (RTO must ≤ MTD). Interview 3 BU heads. Cross-reference against IT system register. Is new ERP included?

ISO 22301 Clause 8.2 · NIST 800-34

2. BCP Documentation — 5 plans (BC-002)

Check scope, activation criteria, recovery steps, alt work location, comms plan, vendor contacts, version currency. Flag any referencing decommissioned systems.

ISO 22301 Clause 8.4

3. Exercise Records — 2 exercises (BC-003)

Review after-action reports. What % of action items from each exercise are closed? Was the prior exercise reviewed before the next one started?

ISO 22301 Clause 8.5

4. Training Records — 42 staff (BC-004)

All recovery team members require training within 12 months. Flag any who've never been trained. Do they know where to find the plan?

ISO 22301 Clause 7.3

5. BCM Policy — governance review (BC-005)

Board-approved within 12 months? Named BCM Manager? MTD/RTO definitions included? Exercise requirements specified?

ISO 22301 Clause 5

6. Crisis Communications Plan (BC-006)

Internal tree, customer notification, media protocol, social media, regulator notifications (UK + EU). Are templates finalized? Is the owner in post?

ISO 22301 Clause 8.4.3

7. BCM Governance — board oversight

Executive sponsor? BCM in annual risk assessment? Board receives status reports? Policy approved at appropriate level?

ISO 22301 Clause 5

BIA (18 processes)

🔍 Exceptions

BC-001Business Impact Analysis v2.1Last reviewed 3 years ago · Owner: Operations Director

#	ID	Process	BU	Owner	Criticality	MTD (hrs)	RTO (hrs)	RPO (hrs)	RTO≤MTD?	Revenue/hr	Recovery Strategy	Reviewed	ERP Dependency	BIA Status

🔍 What to look for — Business Impact Analysis

RTO vs MTD relationship — The Recovery Time Objective must always be less than the Maximum Tolerable Downtime. If RTO ≥ MTD, the organisation will have breached its tolerance before recovery completes. This invalidates the BIA for that process.

Missing processes — The BIA should cover all critical business processes. Look for operational areas or systems that are referenced elsewhere but absent from the BIA. A newly implemented system not yet in the BIA is a gap.

Unrealistic MTD values — An MTD of 30 days for a payroll process means the organisation believes it could survive a month without paying staff. Validate whether MTD values reflect operational reality.

BIA age — When was each BIA record last reviewed? A BIA more than 12 months old may not reflect current operations, especially after system changes or restructuring.

Unknown owners — Process owners listed as "TBC" or blank mean nobody is accountable for that recovery. The plan cannot be activated effectively without named owners.

BCP Plans (5)

🔍 Exceptions

BC-002BCP Plan Documentation Assessment5 plans · SharePoint BCP Library

#	Plan	BU	Version	Updated	Owner	Board Approved	Activation Criteria	Recovery Steps	Alt Location	Comms Plan	Vendors	Decom'd Systems?	Quality	Key Gaps

🔍 What to look for — BCP Documentation

References to decommissioned systems — A recovery plan that instructs staff to use a system that no longer exists will fail on activation. Look for technology references and check whether those systems are still operational.

Plan age and ownership — When was each plan last updated, and is the named owner still in the organisation? A plan owned by someone who left cannot be maintained or executed as intended.

Alternate location viability — The alternate recovery location must be genuinely separate from the primary site. Check whether any alternate sites are in the same building or geographic area — a localised event would affect both.

Contact information currency — Plans containing vendor contacts, emergency services numbers, or staff contact details need to be verified. Outdated contacts mean the plan stalls during activation.

Activation criteria — How does the plan get activated? Vague or subjective triggers (e.g., "when management decides") mean different people may interpret activation differently under pressure.

Exercise Records (2)

🔍 Exceptions

BC-003BCP Exercise After-Action Reports2 exercises · Most recent 18 months ago

#	Exercise ID	Date	Type	Scenario	Participants	Facilitator	Obj. Met	Issues Found	Actions Raised	Actions Closed	% Closed	Next Exercise	Result	Approved By

🔍 What to look for — Exercise Records

Action item closure rate — Every exercise should produce action items. Calculate how many from each exercise have been formally closed. A low closure rate after 12+ months indicates the lessons-learned process is not functioning.

Exercise type diversity — Tabletop exercises test knowledge but not execution. ISO 22301 expects a mix of exercise types including functional/operational drills. A programme with only tabletops has never tested whether the plan actually works.

Frequency — How long since the last exercise? Most frameworks expect at least annual testing. Check the gap between exercises and the current date.

Carry-forward issues — Did the second exercise verify closure of issues from the first? Repeating an exercise without addressing prior findings means the programme is not learning.

Training Records (42)

🔍 Exceptions

BC-004BCP Training Completion Register42 recovery team members · Annual training required

#	Staff ID	Name	Dept	BCP Role	Last Training	Type	Months Since	Within 12mo?	Knows BCP Location?	Notes

🔍 What to look for — Training Records

Overdue training — Calculate how long since each person last completed BCM training. Most policies require annual refreshers. Anyone beyond 12 months from their last training is overdue.

Never trained — Particular attention to staff who have no training record at all, especially if they have been in a recovery role for several months. They have active responsibilities they have never been trained to perform.

Key role holders — The most critical gap is in leadership roles (Recovery Team Lead, Crisis Manager). Check whether the most senior recovery roles have the most current training.

Knowledge retention — Look for any assessment or test associated with training. A training record with no assessment means completion was recorded without evidence of comprehension.

BCM Policy Elements

🔍 Exceptions

BC-005BCM Policy v1.2 ReviewLast board approval: 4 years ago

#	Policy Element	Required By	Present?	Adequate?	Last Updated	Owner	Board Approved?	Notes

🔍 What to look for — BCM Policy

Board approval currency — ISO 22301 expects annual board review and approval of the BCM policy. Calculate how many years ago the last approval was recorded.

Definition of key terms — A BCM policy must define MTD, RTO, RPO, and the scope of the programme. Policies that reference these concepts without defining them leave the programme open to inconsistent interpretation.

Named programme owner — The policy must identify who is accountable for the BCM programme (typically a BCM Manager or equivalent). A vacant role or "TBC" means the programme has no accountable owner.

Scope completeness — Does the policy scope cover all the business units and locations that appear in the BIA? Gaps between policy scope and BIA coverage mean some critical areas are outside the programme.

Crisis Comms Elements

🔍 Exceptions

BC-006Crisis Communications Plan AssessmentPlan v1.0 · 2 years old · Comms Manager role vacant

#	Element	Required By	Present?	Adequate?	Contacts Current?	Templates?	Owner?	Notes

🔍 What to look for — Crisis Communications

Vacant roles — The communications plan requires named individuals for key roles (Media Spokesperson, Internal Communications Lead). Vacant roles mean nobody has authority to speak on behalf of the organisation during a crisis.

Template completeness — Are communication templates fully drafted or do they contain placeholder text? Placeholder text means the template has never been finalised and will require drafting under crisis conditions.

Regulatory notification contacts — Does the plan include contact details for relevant regulators (e.g., port authorities, maritime regulators, data protection authorities)? Missing contacts cause delays in required notifications.

Escalation path — Is there a clear escalation matrix showing who to contact and in what order? An unclear escalation path causes confusion about who has decision-making authority during a crisis.

✍️

Use CCCEE: Condition · Criteria · Cause · Effect · Recommendation. Every element is mandatory. Cite specific record counts, dates, and framework clauses.

FINDING-BC-001

Document Your Finding

Control Area

Risk Rating

Condition — What did you find? (specific: cite numbers, dates, %)

Criteria — Policy/regulation/framework requirement (cite version + section)

Cause — Root cause (process, people, or technology failure)

Effect — Business / regulatory impact

Recommendation — Specific, actionable, with suggested owner and timeline

Management Action Plan — Proposed response from management

// DR Audit Project

NexaBank Digital — DR Audit

Regional bank, $4B assets, 280k customers, regulated by FFIEC. Core Banking, SWIFT, Internet Banking in scope. 14 systems with declared RTO/RPO. Last DR test: 14 months ago. Replication failure ran 8 days undetected.

🚨

Core Banking has NEVER met its 4hr RTO target in testing. SWIFT uses daily tape backup against a 1hr RPO commitment. Regulator exam in 6 weeks.

1Understand Scope

2RTO/RPO Review

3DR Test Results

4Site & Runbooks

5Replication

6Draft Findings

1. RTO/RPO Register — 14 systems (DR-001)

Review each system's RTO and RPO targets. Verify targets were set by business, not IT. Cross-check backup frequency vs RPO — if backup is daily but RPO is 1hr, that's a gap.

FFIEC BCP · ISO 27031

2. DR Test Results — last 2 tests (DR-002)

Did the test achieve RTO? What was declared vs achieved? Were all systems included? Was test declared a pass despite overruns? Were action items from prior test closed before next test?

FFIEC BCP · ISO 22301 Clause 8.5

3. DR Site Readiness (DR-003)

Is the DR site actually capable of handling production load? Check: capacity, network connectivity, licensing, staff access, environmental controls, last physical inspection date.

FFIEC BCP Section VI

4. Recovery Runbooks — 5 systems (DR-004)

Are steps documented to the level a new staff member could execute? Last tested? Owner assigned? Include rollback steps? Reference correct system versions and IPs?

ISO 27031 Section 8.4

5. Replication Monitoring — 90-day logs (DR-005)

Is replication continuous or scheduled? Were failures alerted? Were all failures investigated? The 8-day gap — what caused it, who knew, when was it fixed?

FFIEC BCP · NIST SP 800-34

6. Regulatory Compliance Review

FFIEC BCP requires annual DR test, documented results, board reporting, and remediation tracking. Is there a DR committee? Does board receive test results?

FFIEC BCP Booklet

7. Backup Configuration Verification

Compare each system's backup schedule against its RPO target. Daily tape = 24hr RPO. 1hr RPO requires near-continuous replication. Flag every gap.

FFIEC BCP · ISO 27001 A.12.3

RTO/RPO Register (14)

🔍 Exceptions

DR-001System RTO/RPO Register14 systems · Business + IT declared · Last reviewed 14 months ago

#	System	Tier	Business Owner	RTO Target	RPO Target	Backup Method	Backup Freq	Replication	RTO Achieved (Last Test)	RPO Gap?	Regulator Committed?	Status

🔍 What to look for — RTO/RPO Register

RTO target vs tested performance — For each system, compare the RTO Target against the Last Tested RTO. If the system has never been tested, the RTO is an assumption, not a validated capability.

Backup method vs RPO gap — Calculate the maximum data loss possible under the current backup method. Daily tape backup = up to 24 hours of data loss. If RPO is 1 hour, that is a 23-hour gap in the worst case.

Never-tested systems — Look for critical systems with no test date. Regulators (FFIEC) expect annual testing of critical systems. An untested RTO is an assumed RTO.

Consistency of test results over time — If a system has been tested multiple times, is it consistently meeting targets or consistently failing? A pattern of failure with no remediation is a governance finding.

DR Test Reports (2)

🔍 Exceptions

DR-002DR Test After-Action Reports2 tests · Most recent: 14 months ago

#	Test ID	Date	Type	Systems	RTO Target	RTO Achieved	RPO Target	RPO Achieved	Pass/Fail	Issues	Actions	Actions Closed	Board Notified

🔍 What to look for — DR Test Reports

Declared result vs actual performance — Read the actual recovery times achieved. Then read the declared Pass/Fail result. Do they match? A system that took longer than its RTO target should not be declared PASS.

Pass criteria definition — Were the pass criteria defined before the test began? If the test plan does not define what constitutes a PASS, the result can be declared subjectively.

Test frequency — Calculate the gap since the last test. FFIEC requires annual testing of critical systems at minimum. Check the date of the most recent test for each system.

Scope of systems tested — Were all critical systems included in the test? A test that covered only some systems leaves the untested ones with unvalidated RTOs.

Remediation evidence — If a previous test failed, is there documented evidence of the remediation completed before the next test? Retesting without fixing the underlying issue is meaningless.

Site Readiness Checklist

🔍 Exceptions

DR-003DR Site Readiness AssessmentWarm Site — Bristol Data Centre · Last inspected 22 months ago

#	Control Area	Requirement	Status	Last Verified	Owner	Notes

🔍 What to look for — DR Site Readiness

Capacity gap — The DR site must be able to run the full production workload during a failover. Compare DR site capacity against production requirements for each system. A capacity shortfall means some systems cannot be recovered even if the site is available.

Network bandwidth — The network connection to the DR site must support production traffic volumes. A DR site with significantly lower bandwidth than production will experience performance degradation during failover.

Specialised hardware replication — Some systems require specific hardware (HSMs, specialised appliances). Check whether these are present and operational at the DR site, not just servers.

Last readiness assessment date — When was the DR site last formally assessed? An assessment more than 12 months old may not reflect current configuration at either the primary or DR site.

Runbooks (5)

🔍 Exceptions

DR-004System Recovery Runbooks Assessment5 runbooks · SharePoint DR Library

#	System	Version	Updated	Owner	Step-by-Step?	Rollback Steps?	IP/Config Current?	Tested?	Last Test	Quality	Key Gaps

🔍 What to look for — Recovery Runbooks

Technical accuracy — Runbooks reference specific server names, IP addresses, and system paths. If any of these have changed since the runbook was last updated, the runbook will fail on execution. Look for last-updated dates and compare against known infrastructure changes.

Runbook ownership — Each runbook must have a named owner who is still with the organisation. A runbook owned by someone who has left has no one responsible for keeping it current or executing it.

Walk-through or test evidence — Has the runbook ever been tested? A runbook that has never been executed in a test environment may contain errors that only surface during a real recovery.

Step-by-step completeness — Runbooks with gaps, assumed knowledge, or references to other documents that do not exist will fail under stress. Look for completeness indicators.

Replication Logs (90 Days)

🔍 Exceptions

DR-005Replication Monitoring Logs — 90 DaysZerto + Veeam · Core Banking, SWIFT, Internet Banking

#	System	Method	Target RPO	Monitoring	Failures	Longest Gap	Alert Sent?	Investigated?	Max Data Loss Risk	Status

🔍 What to look for — Replication Logs

Failure sequences — A single replication failure may be a transient issue. Multiple consecutive failures (multiple days in a row) that were not escalated or investigated represent a control breakdown, not just a technical blip.

Alert-to-investigation gap — If an alert fired, when was it investigated? A long gap between alert and investigation means the monitoring control exists but the response control does not.

Systems with no monitoring — Look for critical systems that do not appear in the replication logs at all. Absence may mean no replication is configured, or that replication exists but is not being monitored.

Replication lag — For systems with an RPO, check whether the replication lag at any point exceeded that RPO. Excessive lag means data loss would exceed the agreed threshold if a failure occurred at that moment.

✍️

Use CCCEE: Condition · Criteria · Cause · Effect · Recommendation. Every element is mandatory. Cite specific record counts, dates, and framework clauses.

FINDING-DR-001

Document Your Finding

Control Area

Risk Rating

Condition — What did you find? (specific: cite numbers, dates, %)

Criteria — Policy/regulation/framework requirement (cite version + section)

Cause — Root cause (process, people, or technology failure)

Effect — Business / regulatory impact

Recommendation — Specific, actionable, with suggested owner and timeline

Management Action Plan — Proposed response from management

// IT Risk Assessment Project

StartFast Tech — IT Risk Register Review

Series B SaaS startup, 180 staff, $45M ARR, ISO 27001 certification scope under review. 28-risk register submitted to board quarterly. One Critical risk was accepted without board sign-off. Residual > Inherent error on 3 risks.

1Understand Scope

2Risk Register

3Heat Map

4Appetite & Plans

5Treatment Review

6Draft Findings

1. Risk Register Completeness — 28 risks (RR-001)

Every risk needs: owner, inherent score, control description, residual score, treatment plan, target date, and status. Flag any where residual > inherent (mathematically impossible without errors).

ISO 31000 · NIST RMF

2. Risk Scoring Validation (RR-001)

Recalculate Likelihood × Impact for each risk. Do the scores match the documented ratings? Are Critical risks (score ≥ 20 on 5×5) being correctly identified?

High RiskISO 27005

3. Heat Map Review (RR-002)

Does the heat map match the register data? Are any Critical risks plotted in Low zones? Is the heat map used in board reporting?

ISO 31000 Section 6.4

4. Risk Appetite Statement (RR-003)

Board-approved? Does it define thresholds for each risk category? Are any accepted risks beyond stated appetite? Is appetite reviewed annually?

ISO 31000 · COSO ERM

5. Treatment Plan Execution (RR-004)

For each risk with "mitigate" treatment: is there an action plan? Owner? Target date? Are overdue actions tracked? Has anything been accepted that should be mitigated?

ISO 31000 Section 6.5

6. Board Reporting Quality

Are board reports accurate representations of the register? Has any Critical risk been sanitized or downgraded before board presentation? Is the board getting the real picture?

ISO 31000 · COSO ERM

Risk Register (28)

🔍 Exceptions

RR-001IT Risk Register v3.128 risks · Quarterly board report · Risk Manager: C. Nwosu

#	Risk ID	Risk	Category	Owner	Likelihood	Impact	Inherent	Controls	Likelihood (R)	Impact (R)	Residual	Treatment	Target Date	Status

🔍 What to look for — Risk Register

Residual vs inherent relationship — Inherent risk is the risk before controls. Residual risk is what remains after controls. Residual must always be ≤ Inherent. If residual exceeds inherent, it means controls are somehow making things worse — mathematically impossible and a data integrity error.

Board approval for accepted risks — Most risk frameworks require explicit board or senior committee approval for risks where treatment = Accept, especially at Critical or High levels. Look for Accepted risks and check whether approval is documented.

Risk ownership — Risk owners should be business function leads who are accountable for the risk and its treatment. IT team names as owners of business risks may indicate the risk ownership model is not embedded in the business.

Treatment plan overdue — Check target dates for treatment actions. Any target date in the past with no evidence of completion is an overdue action. Calculate how many months overdue each one is.

Interactive Heat Map

🔍 Exceptions

RR-002Risk Heat Map — Current QuarterBased on residual scores · 28 risks

IMPACT →

Likelihood ↓	1-Minimal	2-Minor	3-Moderate	4-Major	5-Critical
5-Almost Certain	RK-21	RK-06 RK-18	RK-01 RK-09	RK-11*	RK-14†
4-Likely	RK-27	RK-15 RK-23	RK-04 RK-12	RK-07* RK-02	RK-08
3-Possible	RK-28	RK-16 RK-24	RK-05 RK-13	RK-17 RK-20	RK-10
2-Unlikely		RK-26	RK-19† RK-22†	RK-25†
1-Rare			RK-03

* See footnote † See footnote

🔍 What to look for — Risk Heat Map

Plotting accuracy — Each risk has a numeric score. Map those scores against the heat map zones. A risk scored in the Critical range (e.g., 20+) should appear in the Critical zone on the heat map — not in a lower zone.

Accepted risks visibility — Risks with treatment = Accept should be clearly visible on the heat map so the board can see what they are accepting. Hidden or excluded accepted risks undermine board oversight.

Appetite boundary alignment — Compare the positions of all risks against the stated risk appetite boundary. Any risk beyond the appetite boundary without documented board exception is a governance finding.

Risk Appetite Statement

🔍 Exceptions

RR-003Risk Appetite Statement v1.0Last board approval: 2 years ago · CEO + CFO signed

#	Category	Appetite Level	Threshold	Escalation Trigger	Board Approved?	Risks Beyond Appetite	Status

🔍 What to look for — Risk Appetite Statement

Consistency with register — Cross-reference the stated appetite (e.g., "Low" for cybersecurity) against actual risk decisions in RR-001. If a Critical cybersecurity risk has been Accepted, that directly contradicts a Low appetite unless there is a documented board exception.

Currency — When was the appetite statement last reviewed and approved? An appetite statement more than 12 months old may not reflect the organisation's current strategic position or recent material events.

Coverage gaps — Does the appetite statement cover all risk categories that appear in the register? A category in the register with no corresponding appetite statement means there is no stated tolerance for that risk.

Specificity — Vague appetite statements ("we accept some risk") are not useful. The statement should define thresholds — specific scores, financial amounts, or frequency metrics — that define where the boundary sits.

Treatment Plans

🔍 Exceptions

RR-004Risk Treatment Action PlansActive mitigation actions · Current quarter

#	Risk ID	Treatment	Action	Owner	Target Date	Status	Months Overdue	Evidence	Notes

🔍 What to look for — Treatment Plans

Overdue actions — Compare target dates against today. Calculate months overdue for each action. An action 9+ months past its target date with no escalation evidence suggests the treatment programme has broken down.

Missing evidence — Each completed action should have supporting evidence. Actions marked complete without evidence cannot be relied upon — you cannot confirm the control was actually implemented.

Rolling target dates — Look for actions whose target dates appear to have been extended multiple times. Repeated extensions without resolution evidence indicate the action is not being taken seriously.

Escalation for critical overdue items — Were overdue items escalated to the risk committee or board? The absence of escalation evidence for long-overdue critical risk treatments is itself a governance finding.

✍️

Use CCCEE: Condition · Criteria · Cause · Effect · Recommendation. Every element is mandatory. Cite specific record counts, dates, and framework clauses.

FINDING-RK-001

Document Your Finding

Control Area

Risk Rating

Condition — What did you find? (specific: cite numbers, dates, %)

Criteria — Policy/regulation/framework requirement (cite version + section)

Cause — Root cause (process, people, or technology failure)

Effect — Business / regulatory impact

Recommendation — Specific, actionable, with suggested owner and timeline

Management Action Plan — Proposed response from management

// Audit Documentation Lab

Workpaper Lab — Cross-Engagement

Advanced module. Study 3 completed workpapers from real audit scenarios. Review 12 full CCCEE benchmark findings with strong/weak management action plan examples. Then write your own using the builder.

1Read Workpapers

2WP-001 Access

3WP-002 Change

4WP-003 Backup/DR

5Benchmark Study

6Draft Findings

1. Study WP-001 — Access Control Workpaper

Read objective, scope, population, sampling methodology, test procedures, results, and conclusions. What makes this workpaper complete? What evidence is cited for each exception?

IIA Standards 2310 · PCAOB AS 1105

2. Study WP-002 — Change Management Workpaper

Examine how stratified sampling is documented. How does the auditor justify the sample sizes? How are unauthorized changes escalated in the workpaper?

IIA Standards · COBIT BAI06

3. Study WP-003 — Backup & DR Workpaper

Multi-system, multi-control test. Study how conclusions are drawn across different systems with different results. How is an overall opinion formed from mixed evidence?

IIA Standards · ISO 27001 A.12.3

4. Review 12 Benchmark Findings

Study each CCCEE finding. Compare strong vs weak management action plans. Identify what makes a finding "defensible" — can you trace condition to criteria to effect to recommendation?

IIA Standards 2400 · CCCEE Framework

5. Write 3 Original Findings Using the Builder

Pick one finding from each of 3 different domains. Write using CCCEE. Rate your own. Get peer review. Target: Criteria includes a specific standard clause, Effect includes a business impact statement.

IIA Standards 2410

6. Draft a Management Response

Write a management action plan for your highest-rated finding. Include: disagree/agree, action owner, specific action steps, and target date. Compare to benchmark MAPs — is yours strong or weak?

IIA Standards 2440 · PCAOB

WP-001Access Control — User Provisioning & TerminationsMeridian Financial · ITGC Audit · Senior Auditor: J. Osei · Reviewed: A. Mensah

Objective

Assess whether user access provisioning and termination controls are operating effectively

Test that: (1) access is provisioned only upon approved request; (2) terminated employee access is revoked within SLA; (3) no unauthorized provisioning occurred in the audit period.

Scope & Population

320 active users (SAP + AWS IAM) · 47 terminations · Jan 1 – Dec 31

Sources: PBC-001 (user listing), PBC-002 (HR terminations), PBC-003 (privileged accounts). Population completeness verified by reconciling IT system export against HR headcount report.

Sampling & Test Procedures

Provisioning: 25/320 (random) · Terminations: 25/47 (random)

For each provisioning sample: (1) obtained request ticket; (2) confirmed ticket predates account creation; (3) confirmed manager approval on ticket; (4) confirmed role matches request.

For each termination sample: (1) obtained HR term date from Workday; (2) confirmed IT ticket raised same day (involuntary) / next business day (voluntary); (3) confirmed access revoked in all in-scope systems.

Results — Provisioning Exceptions

3 exceptions identified in 25 samples (12% exception rate)

EXC-001 (MFS-241): Account created Nov 5, ticket dated Nov 12. Retroactive provisioning, 7 days. No approval predating creation.
EXC-003 (MFS-156): CEO account — approved by self. Policy requires independent manager approval.
EXC-007 (MFS-290–293): 4 contractor accounts with no expiry date set. Policy requires 90-day maximum for contractors.

Results — Termination Exceptions

2 exceptions identified in 25 samples (8% exception rate)

EXC-008 (EMP-203 / T. Blackwood): Terminated Oct 3, access revoked Nov 6. 34 days. SLA: 1 business day.
EXC-009 (EMP-118 / F. Okafor): No IT ticket raised. Access revocation not evidenced. Access may still be active.

Conclusion

CONTROL DEFICIENCY — High

Access provisioning and termination controls are not operating effectively. 5 exceptions across 50 samples (10% blended rate). One exception constitutes a potential ongoing access risk (EMP-118). Exception rate exceeds SOX materiality threshold. Two findings raised: FINDING-ITGC-001 (Termination Controls) and FINDING-ITGC-002 (Provisioning Controls).

WP-002Change Management — Approval & Emergency Change ControlsMeridian Financial · ITGC Audit · Senior Auditor: J. Osei

Objective

Assess whether change management controls ensure authorized, tested, and documented changes

Test that: (1) normal changes are approved prior to deployment; (2) test evidence exists; (3) emergency changes have retrospective review within 5 business days; (4) backout plans are documented.

Population & Stratified Sample

312 total changes: 198 Normal · 79 Standard · 35 Emergency

Sampling methodology: Normal — 13 random (low risk); Standard — 7 random (pre-approved templates); Emergency — ALL 35 (high risk, full population). Stratification rationale documented in audit file. Emergency rate of 11.2% noted as observation — benchmark is <5%.

Results — Emergency Changes

2 exceptions from 35 emergency changes tested

EXC-028 (CHG-0234): Emergency deployed Nov 3. Retro review blank as of Dec 11 (38 days). Policy requires 5 business days.
EXC-031 (CHG-0301): Backout plan reads "Roll back if needed." Not a documented procedure — no steps, no owner, no timeline documented.

Results — Normal Changes

2 exceptions from 13 normal changes tested

EXC-027 (CHG-0187): Deployed Sep 14, approval email timestamped Sep 16. 2-day retroactive approval. Unauthorized deployment per policy.
EXC-029 (CHG-0089, 0112, 0198, 0267): Test evidence marked "N/A — low risk." No formal risk waiver document exists for any of these changes.

Conclusion

CONTROL DEFICIENCY — High

Change management controls have multiple gaps. Emergency change retrospective review process is ineffective. One unauthorized deployment identified in the period. High emergency change rate (11.2%) is a separate observation requiring management attention. Two findings raised.

WP-003Backup Controls & Restore TestingMeridian Financial · ITGC Audit · Senior Auditor: J. Osei

Objective

Verify backup controls ensure data can be recovered within RPO and data is restorable

Test: (1) backup schedule adherence; (2) failure monitoring and response; (3) off-site storage; (4) quarterly restore testing with evidence; (5) observed restore test meets RPO.

Population & Test Approach

8 systems · 90-day backup logs · 4 restore test reports

Backup logs obtained from Veeam console (8 systems, 90 days = 720 expected job completions). Restore test reports obtained from DR team. All 4 available restore reports reviewed (full population — only 4 conducted in period, policy requires quarterly = 4 minimum).

Results — Backup Logs

3 exceptions across 8 systems

EXC-032: Core Banking — 6 failures over 90 days, 4 not investigated within 24hrs (alerting SLA). Zero off-site validation for 60 days.
EXC-033: SWIFT Messaging — daily tape only vs 1hr RPO. Maximum data loss exposure = 23hrs. RPO unachievable with current architecture.
EXC-034: Legacy RPTS-01 — failure rate 8.3% (6/72 jobs). Highest in environment. No root cause investigation on file.

Results — Restore Testing

2 exceptions from 4 restore test reports

EXC-035: Q2 restore test — Core Banking. Recovery time: 9.5hrs vs 4hr RTO. Test declared PASS by IT team. No pass/fail criteria documented in test plan.
EXC-036: SWIFT — not included in any restore test. Most regulated system with no recovery validation.

Conclusion

CONTROL DEFICIENCY — Critical (SWIFT); High (Core Banking, Legacy)

Backup and recovery controls contain critical gaps. SWIFT architecture cannot meet its declared RPO — this represents a fundamental control failure requiring immediate escalation. Core Banking has never demonstrated it can meet its 4hr RTO. Three findings raised at Critical and High rating.

// Benchmark Finding Library

12 Complete CCCEE Findings

Study these model findings. Each contains: Condition, Criteria, Cause, Effect, and Recommendation — plus a management action plan rated Weak, Moderate, or Strong.

CRITICALFINDING-ITGC-001

Terminated Employee Access Not Revoked — 34-Day Exposure

Condition: Testing of 25 of 47 terminations identified that EMP-203 (T. Blackwood, Technology, terminated Oct 3) had SAP and AWS IAM access revoked Nov 6 — 34 business days after termination. Additionally, EMP-118 (F. Okafor) shows no IT deprovisioning ticket and no revocation date — access may still be active.

Criteria: IT Access Management Policy v3.1, Section 4.2 requires access to be revoked within 1 business day of voluntary termination and on the same day for involuntary termination. SOX IT General Controls framework requires timely access revocation as a key preventive control over financial system integrity.

Cause: HR-to-IT notification process relies on a manual email from HRBP to IT Service Desk. No automated trigger from Workday. Termination of EMP-203 was processed on a Friday — email sent Monday morning. EMP-118 notification email not received due to HRBP departing mid-process.

Effect: Terminated employees with active credentials represent an unauthorized access risk to financial systems processing $2B annually. The 34-day exposure for EMP-203 and the potentially indefinite exposure for EMP-118 create risk of unauthorized transactions, data theft, or sabotage. This constitutes a SOX ITGC deficiency that must be evaluated for material weakness.

Recommendation: (1) Immediately verify and revoke all access for EMP-118. (2) Implement automated Workday-to-ServiceNow deprovisioning trigger within 60 days. (3) Establish daily reconciliation report comparing HR terminations against active IT accounts. (4) Define escalation path for HRBP handoffs during transitions.

✅ STRONG MAP: "Management agrees. Action 1: IT Operations will immediately verify and revoke EMP-118 access by [3 business days from report date] — Owner: IT Director. Action 2: IT will implement Workday→ServiceNow automated deprovisioning trigger — Owner: IT Director, Target: 60 days. Action 3: Daily reconciliation report will be added to IT Operations dashboard — Owner: IT Operations Manager, Target: 30 days. Root cause review will be conducted to identify any other instances — Owner: IT Audit Liaison, Target: 14 days."

HIGHFINDING-BC-001

BIA Not Updated Following Major System Change — RTO/RPO Data Unreliable

Condition: The Business Impact Analysis (BIA v2.1) was last reviewed 3 years ago. Since the last review: a new ERP system was deployed (8 months ago), 2 facilities were relocated, and 1 business acquisition added 3 new processes. None of these changes are reflected in the BIA. Additionally, 3 processes reference a decommissioned Legacy TMS system as their primary recovery dependency.

Criteria: ISO 22301:2019 Clause 8.2.2 requires the BIA to be reviewed at planned intervals and when significant changes occur. Coastal Logistics BCM Policy Section 3.1 states the BIA shall be reviewed annually and following any material operational change.

Cause: No formal change management trigger exists between the IT Change Advisory Board and BCM team. The BCM function is a collateral duty of the Operations Director with no dedicated resource or review calendar.

Effect: Recovery plans built on an outdated BIA cannot be relied upon. If a disruption occurs, recovery teams will attempt to restore systems against incorrect MTD/RTO targets and use runbooks referencing decommissioned technology. The 2022 ransomware incident cost $3.2M and 11 days downtime — an inaccurate BIA increases the risk and cost of future incidents.

Recommendation: (1) Conduct emergency BIA refresh within 90 days — specifically addressing ERP integration and decommissioned system references. (2) Appoint a dedicated BCM Manager role. (3) Implement mandatory BCM review as part of IT Change Management process for all Tier-1 system changes.

❌ WEAK MAP: "Management acknowledges the finding and will review the BIA in due course. Target: Q3 next year. Owner: Operations Director." — Why weak: No specific actions listed. "In due course" is not a date. Q3 next year is 9 months away for a Critical dependency. No action on decommissioned system references. No root cause addressed.

💡

The full library contains 12 benchmark findings across all 6 domains. Use the Finding Builder below to write your own — then compare your language, specificity, and criteria citations against these models.

✍️

Use CCCEE: Condition (what you found) → Criteria (what should be) → Cause (why it happened) → Effect (business impact) → Recommendation (how to fix). Good criteria cite a specific clause. Good effects cite a specific risk or dollar amount.

NEW FINDING

Universal Finding Builder

Domain

Rating

Finding Title — be specific: "X not done" not "Access Control Issues"

Condition — cite specific records, quantities, dates

Criteria — cite specific clause, article, or policy section

Cause — root cause, not symptoms

Effect — quantify the risk: financial, operational, regulatory

Recommendation — specific, owned, time-bound

Management Action Plan — strong or weak?

// Admin · User Management

All Accounts

View every registered user, manage their plan, and reset passwords. Share temporary passwords securely.

#	Name	Email	Role	Plan	Joined	Actions

// Admin · Stats

Platform Overview

Live counts for the current session.

Real Audits. Real Evidence. Zero Fluff.

Meridian Financial Services Inc.

HealthBridge Corp — GDPR/HIPAA Review

Coastal Logistics Ltd — Post-Ransomware BCP Audit

NexaBank Digital — DR Audit

StartFast Tech — IT Risk Register Review

Workpaper Lab — Cross-Engagement

12 Complete CCCEE Findings

Simple, transparent pricing

All Accounts

Platform Overview