SOC 1 (SSAE 18 / ISAE 3402)

Backups of in-scope financial system data are performed according to documented schedules and retention requirements

• Backup policy
• Backup schedule documentation

• Backup jobs fail silently without alerting to operations
• Scope of backups excludes critical application databases or configuration data
• Backup schedules not aligned to data criticality or RPO requirements
• Job completion evidence not retained for the audit period
• No documented owner accountable for daily backup status review

Backup restoration is tested periodically to verify recoverability of in-scope data

• Restoration test procedure
• Annual test plan

• Restoration tests performed only on non production data sets
• Test cadence informal and not consistently executed each period
• Test results not formally documented with pass or fail conclusions
• Restored data integrity not validated against source
• No remediation tracking when restoration tests fail

Backups of in-scope data are stored at offsite or alternate locations and protected by encryption

• Backup storage standard
• Encryption standard

• Offsite copies stored in the same availability zone as primary
• Encryption keys for backup media not rotated or escrowed
• Tape or media transport chain of custody not documented
• Cloud backup buckets lack object lock or immutability settings
• Key management responsibilities not separated from backup operations

Changes to in-scope production systems are authorized and approved by appropriate stakeholders before implementation

• Change management policy
• Change request template
• Change Advisory Board (CAB) charter

• Standard changes bypass formal approval without defined criteria
• Approver delegations not documented and approvers self approve
• Approval evidence not captured in the ticketing system
• Business impact and risk assessment fields left blank on tickets
• Approvals occur after deployment to production

Production changes are tested in non-production environments and test results are documented and approved before deployment

• Testing standard
• Test plan template

• Test cases not aligned to change scope or risk
• User acceptance testing skipped for production fixes
• Test results not retained or linked to the change record
• Regression testing absent for shared platforms
• No test environment parity with production

Developers cannot deploy their own changes to production; deployment is performed by separate personnel or automated pipelines with controls

• SoD policy for SDLC
• Deployment procedure

• Developers retain standing production deployment access
• Break glass deployment accounts shared across staff
• Pipeline service accounts unrestricted and unmonitored
• No compensating review when SoD cannot be enforced
• Audit logs of deployer identity not retained

Emergency changes follow an expedited but documented approval process and receive retroactive review

• Emergency change procedure

• Emergency change definition overly broad and overused
• Post implementation review not completed within defined window
• Retroactive approvals lack independent reviewer
• Emergency change population not reconciled to ticketing data
• No metrics tracking volume or root cause of emergency changes

Changes to infrastructure components and databases supporting in-scope financial systems follow the change management process

• Infrastructure change procedure
• Database change standard

• Direct database changes performed outside the ticketing process
• Infrastructure as code drift not detected or remediated
• Privileged DBA accounts not reviewed for change activity
• Schema changes not captured with before and after evidence
• Configuration baselines for infrastructure not defined

Batch jobs supporting financial processing are scheduled, executed, and monitored; failures are identified and resolved timely

• Job scheduling procedure
• Batch job inventory and runbook

• Batch job failures not routed to a monitored queue
• No documented runbook for recurring failed jobs
• Schedule changes occur without change ticket coverage
• Dependencies between jobs undocumented
• Stale or obsolete jobs remain enabled in the scheduler

Operational incidents affecting in-scope systems are identified, logged, prioritized, resolved, and reviewed

• Incident management policy
• Incident priority matrix

• No distinction between incident and problem records
• Root cause analyses not completed for repeating incidents
• Severity classification inconsistent across teams
• Customer impacting incidents not communicated to stakeholders
• Lessons learned not fed back into preventive controls

System capacity and performance metrics are monitored and reviewed to ensure in-scope systems meet operational requirements

• Capacity management procedure

• Thresholds set too low generating alert fatigue
• Capacity plan not refreshed against business forecasts
• Performance baselines not established for critical systems
• Trend reports not reviewed by accountable management
• No action tracking when thresholds are breached

Input validation, processing controls, and reconciliations ensure financial data is processed completely and accurately

• Data processing control documentation
• Reconciliation procedure

• Input validations bypassed by privileged users
• Reconciliation totals not retained as audit evidence
• Error queues not worked within defined timeframes
• Manual journal entries lack independent review
• Calculation logic changes deployed without recertification

Data interfaces and file transfers to and from in-scope systems are monitored for completeness, accuracy, and authenticity

• Interface design documentation
• File transfer standard

• Hash or record count checks not performed on inbound files
• Failed transfers retried without operator review
• Sensitive files transmitted over unencrypted channels
• Interface monitoring lacks alerting for missed runs
• No documented data dictionary for interface payloads

A documented incident response plan addresses security incidents affecting in-scope financial systems

• Incident response plan
• IR roles and responsibilities matrix
• Communication plan

• Plan not tested through tabletop or live exercises annually
• Roles and contacts within the plan are stale
• Escalation thresholds undefined or inconsistent
• Plan not aligned to regulatory notification timelines
• No post incident metrics tracked at executive level

Security incidents impacting financial-system integrity are detected, escalated, contained, and remediated per the IR plan

• IR runbooks
• Escalation matrix

• Detection rules not tuned for the current environment
• Mean time to detect and respond not measured
• Forensic evidence preservation procedures absent
• No 24x7 coverage or on call rotation defined
• Threat intelligence not integrated into detection logic

New user access to in-scope financial systems is approved and provisioned based on documented authorization aligned with job responsibilities

• Access provisioning procedure
• New hire access request form
• Approval workflow documentation
• Role-to-system mapping matrix

• Access requests approved without documented business need
• Role definitions overly broad granting excessive entitlements
• Joiner workflow not synchronized with HR start dates
• Approvers and requesters are the same person in some cases
• Provisioning evidence not retained for the audit period

Access to in-scope systems is revoked timely upon termination or role change to prevent unauthorized financial transactions

• Termination procedure
• HR offboarding checklist
• Access removal SLA documentation

• Termination notifications delayed beyond same business day
• Contractor and third party accounts not included in leaver process
• Federated identities orphaned after directory cleanup
• No periodic reconciliation between HR and access systems
• Shared accounts not rotated after staff departure

User access to financially relevant systems is reviewed periodically by system owners to confirm continued appropriateness

• User access review procedure
• Review schedule and scope documentation
• Review certification template

• Reviews rubber stamped without meaningful evaluation
• Privileged and service accounts excluded from scope
• Review cadence inconsistent across in scope systems
• Remediation actions not tracked to closure
• Reviewer independence from the access population not maintained

Privileged and administrative access to in-scope systems is restricted, approved, monitored, and reviewed

• Privileged access policy
• Privileged role inventory
• PAM tool configuration documentation

• Standing privileged access in place rather than just in time
• Session recordings not enabled or reviewed
• Privileged account inventory incomplete
• Password vault not enforced for all privileged credentials
• No separate identity for administrative versus daily use

Authentication configurations for in-scope systems enforce password complexity, length, expiration, and lockout aligned with policy

• Password policy
• Authentication standard

• Password policy not enforced consistently across all systems
• Service accounts exempt from rotation without compensating control
• Legacy authentication protocols still enabled
• Account lockout thresholds set too lenient
• Configuration drift from baseline not detected

Multi-factor authentication is enforced for remote access and privileged access to in-scope systems

• MFA policy
• Remote access standard

• MFA bypass exceptions granted without expiry
• SMS used as the only second factor for privileged users
• Legacy clients exempted from MFA enforcement
• Inherited or persistent sessions weaken MFA value
• No alerting on repeated MFA failures or push fatigue patterns

Conflicting duties within financially relevant applications are segregated to prevent a single user from initiating and approving the same transaction

• Segregation of duties matrix
• Role definition documentation

• SoD ruleset not documented or maintained
• Conflicting roles assigned to single users without mitigation
• Mitigating controls exist but are not evidenced or reviewed
• Custom roles bypass standard SoD analysis
• No periodic SoD violation reporting to finance leadership

Security-relevant events on in-scope systems are logged, retained, and protected from unauthorized modification

• Logging and monitoring standard
• Log retention schedule

• Critical systems do not forward logs to central collection
• Log retention falls short of regulatory requirements
• Log integrity protections such as write once storage missing
• Time synchronization across sources inconsistent
• Audit log access not restricted or reviewed

Intrusion detection and security alerting mechanisms monitor in-scope systems and generate alerts for investigation

• Detection rule documentation
• Alert tuning procedure

• Detection coverage limited to perimeter with no internal sensors
• Alert triage SLAs not defined or not measured
• False positive tuning not performed regularly
• Out of hours coverage absent or undocumented
• Integration with incident response workflows incomplete

Vulnerabilities on in-scope systems are identified through scanning, prioritized, and remediated within defined SLAs

• Vulnerability management policy
• Remediation SLA matrix

• Authenticated scans not used leaving findings shallow
• Remediation SLAs by severity not defined or enforced
• Risk acceptances lack documented rationale and expiry
• Asset inventory used for scanning is incomplete
• Exception backlog grows without executive visibility

New development of in-scope systems follows a documented SDLC including requirements, design, development, testing, and deployment

• SDLC policy
• SDLC gates documentation

• SDLC documentation not updated for current delivery model
• Security and privacy requirements not integrated into design
• Stage gate evidence inconsistent across teams
• No defined criteria for production readiness
• Third party components introduced without review

Code changes to in-scope systems receive peer review and security scanning before merge to production branches

• Secure coding standard
• Code review policy

• Code review requirements bypassed under deadline pressure
• Static analysis findings not triaged or tracked
• Secrets detected in source repositories without remediation
• Developers lack secure coding training records
• Dependency vulnerabilities not blocked at the pipeline

A risk assessment process identifies risks to in-scope financial processing and informs the design of controls

• Risk assessment policy
• Risk register

• Risk assessment performed only at scoping rather than continuously
• Process changes not reassessed for ICFR impact
• Fraud risk factors not explicitly considered
• IT risks not linked to financial assertions
• Results not communicated to control owners

Physical access to data centers hosting in-scope systems is restricted to authorized personnel

• Physical access policy
• Data center access procedure

• Visitor escort policy not consistently enforced
• Badge access lists not reconciled to HR records
• Subservice data center reports not obtained or reviewed
• Tailgating not addressed by physical controls
• Termination of physical access lags logical termination

Physical access rights to data centers and restricted areas are reviewed periodically by responsible owners

• Physical access review procedure

• Reviews conducted by personnel lacking site knowledge
• Privileged badge holders not separately reviewed
• Review frequency exceeds policy interval
• Remediation of revoked access not tracked to completion
• No reconciliation to terminated employee population

Subservice organizations (cloud hosting, key SaaS) supporting in-scope systems are monitored through SOC reports or equivalent assurance

• Vendor management policy
• Subservice organization list and carve-out/inclusive method documentation

• SOC reports not reviewed within required timeframe
• Bridge letters not obtained to cover audit period
• Identified exceptions not assessed for impact on user entity
• No defined owner for subservice monitoring
• Complementary subservice controls not mapped to user controls

The service organization communicates complementary user entity controls that customers must implement for the service organization controls to be effective

• CUEC list
• Customer-facing documentation

• CUECs not published clearly in contracts or trust documentation
• Customer assumptions about service responsibilities misaligned
• No process to confirm customer implementation of CUECs
• CUECs not updated when service offering evolves
• Sales and onboarding teams unaware of CUEC obligations