0%
0 of 74 answered
Control Environment
0/6
Communication and Information
0/3
Risk Assessment
0/5
Monitoring Activities
0/3
Control Activities
0/3
Logical and Physical Access Controls
0/13
System Operations
0/9
Change Management
0/2
Risk Mitigation
0/3
Availability
0/7
Confidentiality
0/6
Processing Integrity
0/6
Privacy
0/8

📜 SOC 2 Readiness Assessment

The report shows what an auditor would be likely to raise for it, and the fewest controls that bring your scores there.
Auto-saved to your browser
Control Environment 0/6 ▼
Does your organisation have a documented code of conduct or ethics policy?
Covers COSO Principle 1 — the tone-at-the-top commitment SOC 2 auditors look for first (AICPA CC1.1).
Does an independent body (board, advisory board, or equivalent) provide oversight of the system of internal control?
For an SME without a formal board, describe whoever holds this oversight role structurally (AICPA CC1.2).
Are reporting lines and decision-making authority for security clearly documented (org chart, RACI, or equivalent)?
Auditors check that authority for security decisions is traceable, not assumed (AICPA CC1.3).
Does your organisation have a defined process for hiring, training, and evaluating staff in security-relevant roles?
Job descriptions, onboarding security training, and role-specific competency checks all count as evidence (AICPA CC1.4).
Is accountability for specific internal control responsibilities formally assigned to named individuals or roles?
A responsibility matrix or named control owners, not day-to-day informal delegation (AICPA CC1.5, design half).
Is there evidence that accountable individuals are actually held to those responsibilities (performance reviews, escalations, documented follow-up)?
A Type II auditor looks for follow-through, not just an assignment on paper (AICPA CC1.5, operating half).
Communication and Information 0/3 ▼
Does your organisation generate and use reliable information (metrics, logs, reports) to support security decision-making?
Dashboards, SIEM output, or regular security reporting all count (AICPA CC2.1).
Are security policies and responsibilities communicated to all employees, and updated when they change?
An intranet policy library or induction pack that is actually kept current, not a one-time PDF from three years ago (AICPA CC2.2).
Does your organisation communicate security commitments and incidents to customers, regulators, or other external parties as needed?
A public security page, breach-notification process, or customer-facing status page (AICPA CC2.3).
Risk Assessment 0/5 ▼
Are security objectives documented clearly enough to identify risks against them?
Objectives such as protecting customer data confidentiality only work as a risk-assessment anchor if they are written down (AICPA CC3.1).
Does your organisation have a documented risk assessment process covering security and technology risks?
A risk register, methodology document, or equivalent (AICPA CC3.2, design half).
Has a risk assessment actually been performed within the last 12 months?
A process that exists on paper but has not run recently will not satisfy a Type II auditor (AICPA CC3.2, operating half).
Does your risk assessment process explicitly consider the potential for fraud?
Even a brief section addressing insider threat or fraud vectors is enough evidence (AICPA CC3.3).
Is risk reassessed when significant changes occur, such as new systems, major staff changes, or new markets?
Evidence that risk assessment is not a fixed annual event disconnected from real change (AICPA CC3.4).
Monitoring Activities 0/3 ▼
Is there a defined programme for evaluating whether controls are operating as intended, such as internal audit or control self-assessment?
A schedule or programme document, not ad hoc spot-checks (AICPA CC4.1, design half).
Have control evaluations actually been performed and evidenced in the last 12 months?
Meeting minutes, audit findings logs, or completed checklists count as evidence (AICPA CC4.1, operating half).
Are control deficiencies communicated to those responsible for corrective action in a timely manner?
An issue-tracking process for control gaps, not just informal conversation (AICPA CC4.2).
Control Activities 0/3 ▼
Are specific control activities documented as mitigating specific identified risks?
Traceability from risk register to control, even informally (AICPA CC5.1).
Are general technology controls, such as access management, change management, and operations, formally defined?
This sets up the CC6-CC8 questions below — a high-level confirmation that these control families exist as a set (AICPA CC5.2).
Are control activities implemented through documented policies and procedures, not informal practice alone?
The written policy library itself, distinct from whether it is followed, which is covered elsewhere (AICPA CC5.3).
Logical and Physical Access Controls 0/13 ▼
Is there a defined access control architecture, such as an identity provider, SSO, and role definitions, protecting information assets?
Entra ID, Okta, or equivalent, with roles defined — not shared logins (AICPA CC6.1, design half).
Is there evidence access controls are actually enforced, such as access denial logs?
If you are already connected via the Entra ID or Okta integration this can pull directly from live signal data (AICPA CC6.1, operating half).
Is there a documented process for registering and authorising new users before granting access?
An onboarding checklist or automated provisioning workflow (AICPA CC6.2, design half).
Is there evidence that access is removed promptly when someone leaves or changes role?
Timely deprovisioning is one of the most commonly-tested Type II controls — auditors sample leaver records against access logs (AICPA CC6.2, operating half).
Are roles and permissions defined on a least-privilege basis?
Role definitions that map to job function, not blanket admin access (AICPA CC6.3, design half).
Are user access rights periodically reviewed and evidenced?
Quarterly or more frequent access recertification with a documented sign-off (AICPA CC6.3, operating half).
Are physical access controls in place for any facilities housing information assets?
Mark N/A if fully cloud-hosted with no owned or leased data centre or office server room (AICPA CC6.4).
Is access to assets removed when no longer needed for a role, project, or vendor engagement?
Distinct from the leaver question above: access granted for a project, a temporary role or a supplier is removed when it ends (AICPA CC6.2, CC6.3).
Are network boundary protections, such as firewalls and segmentation, in place against external threats?
Firewalls, security groups or segmentation, with rules reviewed. The External Attack Surface & Breach Check above shows what can be reached from the internet (AICPA CC6.6).
Are there controls restricting how information is transmitted, moved, or removed from the environment?
DLP tooling, encrypted transmission requirements, or removable-media restrictions (AICPA CC6.7).
Are controls in place to prevent, detect, and respond to malicious software?
EDR or antivirus deployment — feeds from the CrowdStrike integration where connected (AICPA CC6.8).
Is multi-factor authentication enforced for access to production systems and sensitive data?
Enforced, not just offered, for every account that can reach production systems or sensitive data, administrators and remote access included. One of the controls auditors most often test (AICPA CC6.1).
Is privileged or administrative access restricted to a limited, named set of individuals and monitored separately from standard user access?
A short, named list of administrators using separate admin accounts, with their use logged and reviewed. One of the controls auditors most often test (AICPA CC6.1, CC6.3).
System Operations 0/9 ▼
Is monitoring or detection tooling deployed to identify security anomalies, such as SIEM or vulnerability scanning?
The tooling exists and is configured to cover production systems (AICPA CC7.1, design half).
Is there evidence that alerts and scan findings are actually reviewed and acted on?
An alert triage log or remediation tracker — tooling that nobody looks at does not satisfy Type II testing (AICPA CC7.1, operating half).
Are system components monitored for anomalies that could indicate malicious activity, errors, or disruption?
Overlaps the previous question in practice — a brief confirmation is sufficient if already covered above (AICPA CC7.2).
Is there a defined process for evaluating whether a security event has, or could, impact objectives?
A triage and escalation criteria document (AICPA CC7.3).
Is there a documented incident response plan?
Roles, escalation paths, and communication steps defined (AICPA CC7.4, design half).
Has the incident response plan been tested, such as a tabletop exercise, or actually invoked in the last 12 months?
A plan that has never been exercised is a common Type II exception (AICPA CC7.4, operating half).
Are activities defined to recover from identified security incidents?
Distinct from business-continuity recovery, covered under Availability if elected — this is incident-specific recovery (AICPA CC7.5).
Is there a defined vulnerability management process with target remediation timeframes by severity?
A fix timeframe for each severity, for example critical within 14 days (AICPA CC7.1, design half).
Is there evidence vulnerabilities are actually remediated within those timeframes?
Scan reports and patch records showing when each finding was fixed. Auditors sample findings and check the dates (AICPA CC7.1, operating half).
Change Management 0/2 ▼
Is there a documented process for authorising, testing, and approving changes to infrastructure, software, and data?
A change management policy or CAB process definition (AICPA CC8.1, design half).
Is there evidence changes are actually reviewed and approved before deployment, such as code review records, change tickets, or deployment logs?
One of the most heavily-sampled Type II controls — auditors typically pull a sample of recent production changes and trace them back to an approval record (AICPA CC8.1, operating half).
Risk Mitigation 0/3 ▼
Are risks from potential business disruptions identified and mitigated?
Overlaps Availability's business-continuity questions if that category is also elected — kept here as the baseline Security-only view (AICPA CC9.1).
Is there a defined process for assessing risk from vendors and business partners?
A vendor risk policy or questionnaire process — the Third Party Risk Hub's own vendor assessment can serve as evidence here (AICPA CC9.2, design half).
Have vendor risk assessments actually been performed for critical suppliers?
Completed vendor questionnaires or Risk Purview scans for key suppliers (AICPA CC9.2, operating half).
Availability 0/7 ▼
Is system capacity monitored and managed to meet demand?
Autoscaling configuration or capacity-planning process (AICPA A1.1).
Are backup processes defined for critical systems and data?
Backup schedule and scope documentation (AICPA A1.2, design half).
Is there evidence backups are actually tested and restorable?
A restore test log — untested backups are a classic audit finding (AICPA A1.2, operating half).
Is a disaster recovery or business continuity plan documented?
RTO and RPO targets and recovery procedures defined (AICPA A1.3, design half).
Has the recovery plan been tested in the last 12 months?
Tabletop or live failover exercise with results recorded (AICPA A1.3, operating half).
Is system uptime monitored against a defined availability commitment?
Uptime tracked and reported against the commitment made to customers, such as a service level (AICPA A1.1).
Is there a defined process for communicating planned or unplanned outages to customers?
A status page or a way of telling customers about planned maintenance and outages (AICPA CC2.3).
Confidentiality 0/6 ▼
Is confidential information identified and classified separately from other data?
A data classification scheme distinguishing confidential customer or business data (AICPA C1.1).
Are secure disposal procedures defined for confidential information?
Data destruction or de-identification procedures (AICPA C1.2, design half).
Is there evidence disposal procedures are actually followed?
Destruction certificates or deletion logs (AICPA C1.2, operating half).
Is confidential information encrypted at rest and in transit?
Current encryption at rest and in transit, and keys managed securely (AICPA CC6.1, CC6.7).
Are confidentiality obligations included in employee and vendor agreements?
Confidentiality clauses in employment contracts and supplier agreements (AICPA C1.1).
Is access to confidential information restricted beyond standard system access controls?
Further limits on top of general system access, such as permissions on the data stores themselves (AICPA C1.1).
Processing Integrity 0/6 ▼
Is information used to monitor processing integrity objectives reliable and relevant?
Reconciliation reports, processing logs, or equivalent quality checks (AICPA PI1.1).
Are there controls over the completeness and accuracy of system inputs?
Input validation, required fields, or reconciliation against source data (AICPA PI1.2).
Are processing controls defined to ensure outputs meet specification?
Documented processing rules or business logic validation (AICPA PI1.3, design half).
Is there evidence processing controls are actually catching errors?
Error logs, exception reports, or QA sign-off records (AICPA PI1.3, operating half).
Are outputs delivered completely, accurately, and on time?
SLA or delivery-tracking evidence (AICPA PI1.4).
Are inputs, in-process items, and outputs stored completely and accurately?
Data integrity controls, such as checksums, versioning, or audit trails (AICPA PI1.5).
Privacy 0/8 ▼
Is a privacy notice published describing what personal information is collected and why?
A public privacy policy meeting this bar (AICPA Privacy series P1 — Notice).
Is consent obtained where required before collecting or using personal information?
Cookie consent, marketing opt-in, or equivalent mechanisms (AICPA Privacy series P2 — Choice and consent).
Is personal information collection limited to what is stated in the privacy notice?
No undisclosed data collection beyond the published notice (AICPA Privacy series P3 — Collection).
Are retention periods defined and enforced for personal information?
A retention schedule with actual deletion or anonymisation at the end of the period (AICPA Privacy series P4 — Use, retention, and disposal).
Can data subjects access, correct, or request deletion of their personal information?
A DSAR, or data subject access request, process (AICPA Privacy series P5 — Access).
Is personal information disclosed to third parties only as described in the privacy notice?
Data processing agreements with any third party receiving personal data (AICPA Privacy series P6 — Disclosure and notification).
Is personal information kept accurate and relevant for its stated purpose?
A data quality or correction process (AICPA Privacy series P7 — Quality).
Is there a process for monitoring privacy compliance and handling complaints?
A named privacy contact or DPO and a complaints-handling process (AICPA Privacy series P8 — Monitoring and enforcement).