Login

10-Step SOC 2 Compliance Checklist for 2026

A useful SOC 2 compliance checklist isn't a policy inventory. It's an evidence-ready operating sequence that connects selected Trust Services Criteria to accountable owners, procedures, platform configurations, recurring reviews, and retrievable records. That distinction matters because SOC 2's standards lineage has evolved across decades, from roots the AICPA traces to the early 1970s, through SSAE 16 in April 2010 and SSAE 18 in May 2017, with today's checklist expressing the framework through control design and operating effectiveness (SOC 2 standards lineage).

The sequence below starts with scope and data, then moves through identity, protection, monitoring, response, people, vendors, and lifecycle controls. Donely's per-instance RBAC, isolated containers, scoped data access, centralized monitoring, and unified audit logs can support control operation and evidence collection, but your organization still has to define the system boundary, select relevant criteria, approve policies, review evidence, and remediate exceptions. Donely's SOC 2 status is in progress, so platform capabilities shouldn't be presented as an attestation.

Prepare in this order: define the service and data flows, map risks and controls to the applicable Trust Services Criteria, assign owners, centralize evidence requests, test controls in operation, remediate gaps, and prepare employees and systems for auditor questions. A readiness assessment typically involves gap analysis, remediation, centralized evidence collection, and employee preparation (practical SOC 2 auditor checklist). Teams commonly need 8–16 weeks of readiness work, while a Type II report adds a 6–12 month observation period, making early scope and evidence decisions essential (SOC 2 readiness timeline). For broader Microsoft governance work, use this guide to regulatory compliance mapping for M365.

Table of Contents

1. Access Control and Identity Management

Access control is where a SOC 2 program becomes operational. Start by documenting who can access each Donely instance, which functions they can use, what data they can retrieve, and which integrations they can authorize. A role definition should be specific enough for an auditor to trace from a job responsibility to a permission matrix, an approval record, and an access review.

Donely's per-instance RBAC and isolated architecture can help separate personal, agency, client, and enterprise workloads. For example, an agency could allow a support operator to work with assigned Zendesk tickets while blocking access to a client's CRM data. An enterprise team could synchronize roles through Okta or Azure AD, while a solo builder might retain broad administrative access in a personal instance but restrict what an agent can do through scoped actions.

Build the control before assigning permissions

Create the permission matrix first. Define standard, administrative, service-account, and emergency roles, then document which data and actions each role requires. Apply least privilege from the beginning, add access only when a business need is approved, and test representative users before production deployment.

Request and retain:

  • Role approvals: Evidence that a manager or system owner approved each privileged role.
  • Provisioning records: SSO, SCIM, or identity-provider records showing how access was granted.
  • Access reviews: Dated reviews showing that owners examined permissions and resolved exceptions.
  • Test results: Screenshots or exported results proving that sample users can access permitted resources and are blocked from restricted ones.

Review unified audit logs for privilege changes, failed authentication, unusual access, and dormant accounts. Donely can help produce platform evidence, but management owns the review decision, the approval trail, and the revocation of unnecessary permissions. Strong identity practices also help teams protect data with IAM.

2. System and Communications Protection

Encryption controls should follow the data, not just the infrastructure diagram. Map every route between Donely instances, AI agents, third-party systems, and end-user channels. That includes API calls to Stripe, Salesforce, or HubSpot, data stored inside isolated containers, and messages exchanged through WhatsApp, Telegram, Discord, or Slack.

The implementation task is to define approved encryption standards for each connection and storage location, then verify that those standards remain active. Don't assume that a vendor's native security feature proves your organization's control. A WhatsApp integration may provide platform-level protections, for example, while your team still needs to document Donely configuration, credential handling, access boundaries, and monitoring around that integration.

Turn encryption into testable evidence

Maintain an integration register that records the data exchanged, transport protection, storage protection, credential owner, and verification method. Store API credentials in a secure vault rather than in application configuration files, tickets, or logs. Validate encryption for every enabled integration before production use, and document what happens when an encrypted connection fails.

A useful evidence packet includes:

  • Architecture records: Current diagrams showing protected data paths.
  • Configuration exports: Settings that demonstrate encrypted transport and protected storage.
  • Credential evidence: Vault ownership and rotation records without exposing secret values.
  • Validation results: Security-scan output or integration testing that confirms the expected protection.
  • Failure testing: Records showing how the team detects, contains, and recovers from encryption or connection errors.

Practical rule: Treat an integration as unapproved until its data path, credential storage, encryption setting, and owner are documented.

Donely's isolated containers and scoped data access can support separation between workloads, but they don't replace your encryption standard, vendor review, key-management process, or auditor-facing evidence. The control belongs to the organization, even when the platform supplies important technical capabilities.

3. Audit Logging and Monitoring

A log becomes useful evidence only when someone knows what it means, who reviews it, and how the organization protects it from alteration. Define required events before deployment. At minimum, map authentication, authorization changes, data access, agent activity, integration changes, administrative actions, and security alerts to control owners and review procedures.

Donely's unified audit logs can help consolidate activity across instances. Consider an agency investigating whether a support employee accessed a customer's Zendesk tickets, or an operator reviewing when an AI agent used a Gmail connection and what permissions were active at that time. These records support detection and investigation, but the organization still needs a documented review cadence and escalation process.

Separate collection from review

Configure alerts for high-risk activity such as privilege escalation, bulk data access, repeated authentication failures, unexpected integration changes, or activity outside an approved workflow. Use asynchronous collection where possible so logging doesn't create avoidable performance pressure, and apply rotation and retention rules that balance audit needs with storage and privacy concerns.

Auditors may request:

  • Event definitions: The documented list of events your system must record.
  • Sample log extracts: Records tied to a defined review period and control owner.
  • Alert tickets: Evidence that high-risk events generated investigation or triage.
  • Integrity checks: Proof that authorized users can't delete or modify historical records.
  • Review signoffs: Dated confirmations showing that personnel examined alerts and resolved exceptions.

A monitoring dashboard isn't the control by itself. The control is the combination of configured collection, protected storage, human review, investigation, and remediation. Donely can make evidence more systematic across isolated instances, while your compliance team must decide whether the available records satisfy the scoped criteria.

Use this walkthrough as a technical aid, then compare its output with your event inventory and auditor requests.

4. Change Management and Configuration Control

A production change should be explainable after the fact. That requires more than a deployment timestamp. Your change process should show what changed, why it changed, who tested it, who approved it, when it reached production, and whether the result matched expectations.

Apply the process to AI agent instructions, integrations, RBAC policies, instance configuration, infrastructure, and security settings. For example, adding a Slack integration should create a request, identify affected data, pass testing in a staging instance, and receive approval before production activation. A risky HubSpot update may require rollback evidence if lead-processing workflows stop working.

Use risk-based approval paths

Not every change needs the same level of review. Define standard, high-risk, and emergency paths. A high-risk change affecting customer data access or privileged roles should require additional approval, while a preapproved routine change may follow a shorter workflow. Emergency changes need a clear exception path and a post-change review, not a permanent exemption from documentation.

Store the following in one change record:

  • Business justification: The reason for the change and expected outcome.
  • Scope assessment: Affected instances, integrations, data classes, and users.
  • Testing evidence: Results from staging or controlled validation.
  • Approval history: Names, roles, decisions, and timestamps.
  • Deployment record: The production implementation and responsible operator.
  • Rollback or follow-up: Recovery steps, observed issues, and post-change review.

Donely can provide controlled instance boundaries and audit records around configuration activity. It can't decide whether a change was sufficiently tested or whether a business owner accepted the risk. Make the reviewer accountable, and keep the evidence attached to the change rather than scattered across chat messages and email.

5. Data Classification and Handling

Data classification gives every later control a reason. Without an inventory of what enters Donely, where it moves, who can access it, and how long it remains, teams tend to apply the same protection to everything or overlook sensitive data hidden inside an ordinary workflow.

Define categories such as public, internal, confidential, and restricted, then document the handling rules for each. Stripe payment information may require restricted handling, customer email addresses may require controlled access and audit logging, and health information in a regulated deployment may need a dedicated classification and handling path. Conversation logs should also have an owner, an access rule, and a retention decision.

Start with the data-flow inventory

List every source, destination, integration, agent, instance, storage location, and human role involved in a workflow. Donely's multi-instance architecture can help keep personal, business, and client workloads separate, but separation doesn't automatically classify the content moving through those environments.

Your evidence request should include:

  • Data inventory: Data types, sources, destinations, owners, and sensitivity.
  • Flow diagrams: Movement between Donely, connected tools, and user channels.
  • Handling rules: Approved access, encryption, export, retention, and deletion actions.
  • Agent boundaries: The data and actions each agent is permitted to use.
  • Review record: Evidence that classifications were reconsidered after material changes.

Automate classification only where the rule is reliable and reviewable. A payment workflow can be flagged as restricted by design, while free-form agent conversations may require human review or conservative defaults. Revisit the inventory whenever a new integration, customer workload, or deployment context changes the system boundary.

6. Vendor and Third-Party Risk Management

Every integration expands the control environment. A vendor may handle customer records, authenticate users, process payments, store messages, or support an AI workflow. Your SOC 2 evidence should show that someone identified those dependencies, assessed their risk, approved their use, and monitored material changes.

Donely supports connections to tools including Gmail, Slack, Notion, HubSpot, Salesforce, Jira, Zendesk, and Stripe. Use the Donely integrations catalog as an operational starting point, then create your own authoritative inventory of enabled connections. The catalog tells you what can connect. Your register must show what is connected in your environment, what data is exchanged, and who owns the risk.

Build tiers instead of treating every vendor equally

A payment processor or CRM generally deserves deeper review than a tool that receives only public information. For critical vendors, request current assurance reports, security documentation, breach-notification terms, data-processing terms, and information about subcontractors. Record the decision, risk rating, compensating controls, and remediation deadline.

Ask owners to retain:

  • Vendor inventory: Service, purpose, data accessed, owner, and status.
  • Assessment package: Questionnaire, assurance report, contract terms, and review notes.
  • Risk decision: Approval, rejection, exception, or compensating control.
  • Monitoring record: Evidence of reassessment after security or service changes.
  • Offboarding proof: Revoked tokens, removed connections, and returned data where applicable.

A vendor's SOC 2 report doesn't transfer responsibility for your configuration. You still own permission scoping, token storage, data minimization, integration monitoring, and the decision to continue using the service.

7. Incident Response and Management

An incident plan must tell people what to do while facts are incomplete. Write the plan around recognizable events in your environment, such as unauthorized access to a Stripe API key, an agent reading Salesforce records outside its approved scope, a compromised Gmail token, or a disruption affecting hosted instances.

Assign an incident lead, technical investigator, communications owner, legal or privacy contact, and executive decision maker. Define severity levels, escalation routes, evidence-preservation steps, customer-notification responsibilities, and recovery criteria. The plan should identify the systems that hold relevant logs and the people authorized to make containment changes.

Test the plan with realistic scenarios

Run tabletop exercises that force the team to use the actual tools and contact paths. A useful exercise starts with an alert, traces activity through unified audit logs, contains the affected instance or credential, evaluates customer impact, records decisions, and verifies recovery. Donely's security policy can inform platform discussions, but your organization needs its own incident procedures, responsibilities, and evidence.

Maintain an incident tracker containing:

  • Detection details: Alert source, time, affected instance, and initial reporter.
  • Investigation notes: Hypotheses, evidence reviewed, and confirmed facts.
  • Containment actions: Disabled accounts, revoked tokens, isolated workloads, or blocked integrations.
  • Communication record: Internal updates, customer notices, and regulatory decisions where applicable.
  • Closure review: Root cause, corrective actions, owner, and completion status.

Don't treat a clean tabletop as proof that the plan works forever. Re-test after major architecture, staffing, integration, or workflow changes, and preserve the exercise record for auditor review.

8. Personnel Security and Onboarding and Offboarding

People create and inherit access, so personnel controls should connect HR events to system records. Define which roles require background checks, which employees or contractors may access production systems, what training they must complete, and who approves exceptions.

An engineer receiving access to customer repositories should have a documented business need and approval. A support employee handling customer issues should understand integration permissions and data-handling rules. When a customer success manager leaves, the offboarding record should show that access, sessions, tokens, devices, and shared credentials were addressed.

Make the joiner and leaver workflow auditable

Use automated provisioning through the identity provider where practical, but keep human approval for sensitive roles. The onboarding packet should include signed policy acknowledgments, security training completion, approved role assignment, and any required screening record. The offboarding packet should include the termination trigger, access-revocation evidence, asset return, token rotation, and manager confirmation.

A compact control register can track:

  • Role eligibility: Screening and access prerequisites.
  • Training status: Initial training, policy acknowledgment, and refresher completion.
  • Access approval: System, instance, role, owner, and justification.
  • Termination action: Revocation timestamp, disabled accounts, and recovered assets.
  • Exception handling: Temporary access, expiry date, and approving authority.

Donely's per-instance boundaries reduce the blast radius of an incorrectly assigned role, but they don't replace HR coordination or manager accountability. Auditors will care whether the process works consistently, not merely whether the platform has an offboarding feature.

9. System Monitoring and Performance Management

Monitoring should answer two questions at once. Is the service operating as expected, and could an abnormal operational pattern indicate a security or control failure? Define service-level indicators for critical workflows before adding every possible metric. Examples include uptime, API latency, error rates, failed synchronization, database health, and unusual agent activity.

A Stripe integration that slows down, a failed HubSpot sync, or delayed database retrieval can affect customers and may also reveal a configuration or dependency problem. Centralized monitoring across Donely instances can give operations teams a common view of status, logs, usage, and incidents, while isolated environments preserve the boundaries needed for client and workload separation.

Build alerts people can act on

Every alert needs an owner, severity, response path, and escalation deadline. Start with the critical functions that customers rely on, then expand as the team learns which signals predict real issues. Excessive false positives train operators to ignore alerts, while thresholds without documented rationale make the control difficult to defend.

Retain evidence such as:

  • Metric definitions: What each indicator measures and why it matters.
  • Dashboard snapshots: Health views tied to a defined review period.
  • Alert history: Trigger, owner, investigation, and resolution.
  • Escalation records: Evidence that serious events reached the right decision maker.
  • Tuning reviews: Records showing that thresholds were evaluated and adjusted.

Review monitoring effectiveness regularly. Donely can centralize operational visibility, but your organization must define acceptable performance, investigate deviations, and connect system events to incident response and change management.

10. Data Retention, Deletion, and Privacy

Retention is a control decision, not a storage default. For each data class, document why the organization keeps the information, where it resides, who can retrieve it, when the retention period ends, and how deletion is verified. Include customer data, conversation logs, credentials, backups, exports, tickets, and audit evidence.

A customer deletion request may require removing associated Salesforce synchronization data, conversation records, and integration credentials across more than one instance. Deactivating a Stripe connection should trigger secure token removal, while the evidence record should preserve what was deleted, when it was deleted, who authorized it, and how the team verified completion.

Make deletion observable

Automate deletion where the rule is stable, but don't rely on an automation job that produces no evidence. Test whether deleted information remains in caches, exports, backups, logs, or connected systems. Keep a deletion ledger that records the request, scope, systems checked, result, exception, and approving owner.

Your retention register should identify:

  • Data category: Content, credential, log, transaction, backup, or audit record.
  • Retention rationale: Legal, contractual, operational, or security purpose.
  • Deletion trigger: Expiry, customer request, integration removal, or account closure.
  • Verification method: System output, review, or destructive-delete test.
  • Exception path: Authorized hold, extended retention, owner, and end condition.

Donely's isolated instances can make customer boundaries easier to identify, but deletion remains a cross-system responsibility. Review your privacy policy alongside customer contracts and applicable obligations, then ensure the operational procedure matches what you promise.

SOC 2: 10-Point Controls Comparison

Control Implementation Complexity (🔄) Resource Requirements (⚡) Expected Outcomes (⭐ / 📊) Ideal Use Cases (📊) Key Advantages (💡)
Access Control and Identity Management (CC6.1 & CC6.2) 🔄 Medium–High, per-instance RBAC, SSO integration ⚡ Moderate, IAM platform, admin overhead, provisioning tooling ⭐⭐⭐, Strong access isolation; audit-ready 📊 Multi-tenant agencies, sensitive integrations (Gmail, Slack, CRM) 💡 Granular least-privilege, clear audit mappings, reduced cross-tenant risk
System and Communications Protection (SC7.1 & SC7.2) 🔄 High, encryption, key & certificate management ⚡ High, HSMs/keystore, automated key rotation, certificate ops ⭐⭐⭐, Confidentiality across channels; regulatory readiness 📊 Payments, healthcare, any high-risk data transit (Stripe, WhatsApp) 💡 End-to-end encryption, MITM protection, supports HIPAA/GDPR readiness
Audit Logging and Monitoring (CC7.2 & CC7.3) 🔄 Medium, centralized immutable logs, alerting ⚡ Moderate–High, SIEM, storage, analysts, retention costs ⭐⭐⭐, Faster detection, forensic evidence for audits 📊 SOC 2 compliance, incident investigations, suspicious activity detection 💡 Immutable trails, real-time alerts, searchable forensic logs
Change Management and Configuration Control (CC7.1) 🔄 Medium, workflows, staging, approvals, rollback ⚡ Moderate, CI/CD, staging envs, approval tooling ⭐⭐, Greater stability and traceability; fewer misconfigs 📊 Production config changes, integration updates, enterprise governance 💡 Versioning & rollback, documented approvals, separation of duties
Data Classification and Handling (CC6.1) 🔄 Medium, data inventory, labeling rules ⚡ Moderate, classification tools, legal/compliance input ⭐⭐, Targeted protections; clearer control scope 📊 GDPR/HIPAA readiness, mixed-sensitivity data flows across integrations 💡 Clear handling rules, automation opportunities, reduced overprotection
Vendor and Third-Party Risk Management (CC9.1) 🔄 High, assessing & monitoring many vendors/integrations ⚡ High, questionnaires, audits, legal reviews, continuous monitoring ⭐⭐, Reduced third-party exposure; contractual safeguards 📊 Large integration ecosystems (850+ tools), critical vendor dependencies 💡 Vendor risk register, SLA/security clauses, prioritized remediation
Incident Response and Management (A1.1 & A1.2) 🔄 Medium, plan, roles, detection & drills ⚡ Moderate, IR team, forensics access, training & exercises ⭐⭐⭐, Faster containment & recovery; regulatory reporting 📊 Breach handling, ransomware, anomalous AI agent behavior 💡 Playbooks, reduced MTTD/MTTR, communication & legal templates
Personnel Security and Onboarding/Offboarding (CC6.2 & PS1.1) 🔄 Low–Medium, background checks, provisioning processes ⚡ Moderate, HR tooling, training platforms, automated workflows ⭐⭐, Lower insider risk; auditable access lifecycle 📊 Staff/contractors with system or data access, privileged roles 💡 Automated provisioning/offboarding, documented responsibilities, surprise reviews
System Monitoring and Performance Management (CC7.2) 🔄 Medium, metrics, synthetic checks, alerts ⚡ Moderate–High, monitoring stack, SRE/ops staff, dashboards ⭐⭐, Improved availability (99.9% SLA) and early issue detection 📊 SLA-driven services, integration health, capacity planning 💡 Proactive alerts, automated remediation, trend-based capacity planning
Data Retention, Deletion, and Privacy (CC6.1 & C1.2) 🔄 Medium, retention policies, legal-hold handling ⚡ Moderate, deletion automation, verification, audit logs ⭐⭐, Lower liability; GDPR/CCPA compliance; storage savings 📊 Privacy-sensitive deployments, GDPR/CCPA requests, log management 💡 Automated deletion, cryptographic erasure, tracked deletion fulfillment

Turn the Checklist Into Audit Momentum

A checklist becomes valuable when it turns into a control register. Create one row for each control objective and record the owner, procedure, system or instance in scope, evidence location, review frequency, exception status, remediation deadline, and auditor request history. This structure prevents a common failure pattern, where a team has a well-written policy but can't retrieve proof that employees followed it.

Scope comes first. Document the service boundary, customer data, environments, integrations, personnel, and relevant Trust Services Criteria before approving technical work. Security is mandatory, while availability, confidentiality, processing integrity, and privacy should be included when relevant to the service and its risks. Over-scoping can create unnecessary audit work, but under-scoping can leave important customer commitments outside the report. Resolve that trade-off with your auditor and customer requirements, not with a generic template.

A practical operating sequence looks like this:

  • Establish scope and inventory: Map systems, instances, data flows, roles, vendors, and criteria.
  • Implement priority controls: Start with identity, data protection, logging, change management, and incident response.
  • Create evidence templates: Define the exact artifact, owner, period, storage location, and review signoff for each control.
  • Operate continuously: Run access reviews, vendor assessments, monitoring reviews, incident exercises, deletion checks, and change approvals during the audit period.
  • Run readiness testing: Reperform control checks, sample evidence, interview owners, investigate exceptions, and close gaps before fieldwork.

The timing deserves a realistic plan. Readiness work commonly takes 8–16 weeks, and a Type II observation period adds 6–12 months before the final report can be issued (SOC 2 planning benchmarks). Automation can change the execution profile. One independent benchmark reported certification in 3.1 months on average with automation versus 6.8 months manually, while also reporting that first-time budgets averaged 2.4 times the original plan, from $35K expected to $84K actual (independent compliance benchmark). Those figures are planning context, not a guarantee for your organization.

The same benchmark identified access-control gaps, including shared credentials, excessive permissions, and missing MFA, in 34% of cases (access-control readiness finding). Fixing identity early therefore has both audit and operational value. Donely's per-instance RBAC, isolated containers, scoped data access, centralized monitoring, and unified audit logs can make evidence collection more systematic, particularly for teams managing multiple personal, business, agency, or enterprise workloads. They don't remove management's responsibility to approve access, review logs, classify data, assess vendors, test response, or correct failures.

Keep the platform claim precise. Donely describes SOC 2 as in progress, so verify current documentation before making customer-facing statements about SOC 2 status. Treat the product as one part of a broader control environment, alongside your policies, people, vendors, auditor, and operating records.

Start by opening a control register today. Assign an owner to scope and data inventory, identify the first evidence requests, and schedule a readiness review that tests whether each control can be demonstrated, not merely described.

Donely provides a unified platform for deploying and managing AI employees across isolated instances, with per-instance RBAC, scoped data access, centralized monitoring, and unified audit logs that support evidence-ready operations. Visit Donely to evaluate how its integrations and multi-instance architecture can fit into your SOC 2 control environment.