TL;DR — Most startups treat SOC 2 prep as a 6-week sprint of screenshots, spreadsheet reconstruction, and frantic policy writing. It doesn’t have to be that way. When your IT operations are automated — access provisioning, deprovisioning, device management, change logging — the audit evidence generates itself. This article shows you what auditors actually look for in IT controls, and how to build the operational layer that produces that evidence continuously, not just when your auditor asks for it.
Your SOC 2 audit is in eight weeks. Your security team has just sent a 200-item evidence request.
Item 47: “Access termination log for all employees who departed in the last 12 months, with timestamps.”
You know what that means: someone is about to spend three days combing through IT tickets, Slack messages, and spreadsheets trying to reconstruct when each account was actually deactivated — not when you intended to deactivate it.
This is the gap between compliance theater and operational compliance. Theater is collecting evidence after the fact, hoping the timestamps line up. Operational compliance is running your IT systems in a way that generates audit-ready evidence as a byproduct of normal operations.
The difference is not more documentation. It’s automation.
What SOC 2 Actually Requires from IT
SOC 2 is built on five Trust Services Criteria. For most startups, the IT controls that matter fall under Security (CC6, CC7) and Availability (A1). The specific controls auditors spend the most time on:
CC6.1 — Logical access controls. Who has access to what, and is it based on job function? Auditors want to see that access is role-based, that privileged access is limited, and that you have a documented process for granting and revoking it.
CC6.2 — Access provisioning and deprovisioning. How do new employees get access? How quickly is access removed when someone leaves? This is where the 90-day stale account problem lives.
CC6.3 — Access reviews. Do you periodically review who has access and whether they still need it? Quarterly is the standard expectation for most auditors.
CC7.2 — Monitoring for anomalies. Are you logging system activity? Do you have a mechanism to detect unauthorized access attempts?
None of these require exotic security tooling. They require process — and automation is what makes process evidence-producing rather than evidence-reconstructing.
The Evidence Auditors Actually Want
Stop thinking about compliance as a documentation exercise. Start thinking about it as a logging exercise.
For CC6.2 — the access provisioning and deprovisioning control — auditors want:
- A timestamped record of when each new hire’s accounts were created
- Evidence that the accounts were created based on their role (not arbitrary)
- A timestamped record of when each departed employee’s access was revoked
- Evidence that revocation happened promptly (same-day or within 24 hours is the standard)
If you’re running manual provisioning, you can produce the first and third items from IT tickets — assuming IT tickets were always filed, which they weren’t. You can’t easily produce the second item (role-based evidence) or the fourth (promptness), because manual processes don’t have reliable timestamps.
If you’re running SCIM (System for Cross-domain Identity Management) provisioning from your IdP (Identity Provider), every single provisioning event is logged automatically. The IdP’s admin log shows: user created at [timestamp], added to group [engineering] at [timestamp], Salesforce account provisioned at [timestamp], GitHub access granted at [timestamp]. That’s your CC6.2 evidence, self-generating.
The same is true for deprovisioning. Our piece on automated employee offboarding security covers the access revocation architecture in detail — the compliance angle is that every SCIM deprovisioning event is timestamped in your IdP’s audit log without any manual documentation effort.
The Five IT Controls That Generate Their Own Evidence
Build these five controls into your IT operations and you’ll walk into a SOC 2 audit with most of the evidence already assembled.
1. HRIS-triggered provisioning and deprovisioning.
Connect your HRIS (Human Resources Information System) to your IdP. New employee record goes active → IdP creates the user → SCIM provisions all connected apps. Employee status changes to terminated → IdP deactivates the user → SCIM deprovisions all connected apps.
Every event in this chain is logged with a timestamp. The log is your evidence. No reconstruction required.
2. Role-based access via IdP groups.
Every account should be provisioned based on group membership (department, role, level), not individual IT judgment. When auditors ask “how do you ensure least privilege?” — the answer is: group membership in the IdP maps to specific roles in each app, and group assignment is tied to the HRIS department field.
This is also what makes access reviews fast. You’re not reviewing individual access decisions. You’re reviewing whether the group definitions are still correct.
3. MDM (Mobile Device Management) enrollment and compliance logging.
Every company-owned device should be enrolled in MDM — Jamf for Mac, Intune for Windows. MDM gives you a continuous, timestamped record of device compliance status: is disk encryption on, is the OS patched, is the endpoint protection agent running?
Auditors checking device security controls (CC6.7) want to see that you can demonstrate device compliance across your fleet. MDM generates that report. Manual inventory spreadsheets do not.
4. Access reviews on a documented schedule.
Set a quarterly calendar event. Pull the IdP’s group membership list. Review it against current employee records from your HRIS. Flag anyone who has access they shouldn’t (role change, department change, access granted temporarily and never removed). Document what you reviewed and what you changed.
The review doesn’t need to be elaborate. It needs to be dated, documented, and repeatable. A shared Google Doc with a quarterly review log is sufficient. The absence of a documented review process is a finding. A simple, consistently-executed one is not.
5. Privileged access management.
Admin accounts — root, global admin, billing admin, database admin — are a separate audit category. Auditors want to see that privileged access is limited to people who actually need it, that it’s reviewed separately from normal access, and that privileged actions are logged.
Practical implementation: maintain a separate privileged access group in your IdP. Require MFA (multi-factor authentication) for all privileged accounts. Log privileged actions in your cloud provider’s audit trail (AWS CloudTrail, GCP Audit Logs, Azure Activity Log). Review the privileged access list monthly, not quarterly.
The short answer: SOC 2 IT compliance doesn’t require expensive GRC software or a dedicated compliance team — it requires that your core IT operations (provisioning, deprovisioning, device management, access reviews) run in a way that generates timestamped, auditable logs. SCIM provisioning through an IdP, MDM enrollment, and role-based access via group membership together produce most of the evidence auditors look for in CC6 and CC7 controls, automatically, as a byproduct of normal IT operations.
The 5 Reasons Startups Fail SOC 2 IT Controls
The most common SOC 2 failure modes for startups cluster around the same operational gaps. Here’s what auditors actually cite:
Stale accounts. Former employees with active accounts are an immediate finding. This is pure offboarding failure. Fix: HRIS-to-IdP deprovisioning automation.
Undocumented access provisioning. “We just set up accounts for new people” is not a control. Auditors want a process — documented, followed consistently, with evidence it was followed. Fix: SCIM provisioning with IdP event logs as evidence.
No access reviews. Many startups have never formally reviewed who has access to what. That’s a finding every time. Fix: quarterly review with a documented log.
Privileged access sprawl. Too many people with admin rights, no review of who has them, no log of what they did with them. Fix: privileged access group, MFA enforcement, cloud audit logging.
Device compliance gaps. Laptops not in MDM, some devices missing encryption, no way to demonstrate patch status. Fix: MDM enrollment for all company devices, compliance reporting baked into the MDM dashboard.
Building the Compliance Evidence Package
When your auditor sends the evidence request, here’s what you pull from each system:
| Control | Source | What you export |
| CC6.2 — Provisioning | IdP admin log | User creation events with timestamps for audit period |
| CC6.2 — Deprovisioning | IdP admin log | User deactivation events within 24h of HRIS termination |
| CC6.1 — Role-based access | IdP group membership | Group-to-app-role mapping + current group membership list |
| CC6.3 — Access reviews | Review log document | Dates, reviewer, what was reviewed, changes made |
| CC6.7 — Device compliance | MDM compliance report | Per-device encryption status, OS version, agent status |
| CC7.2 — Monitoring | Cloud audit logs | Privileged action logs for the audit period |
This package takes about two hours to pull if your systems are configured correctly. It takes two weeks if they’re not.
Continuous Compliance vs. Point-in-Time Prep
The traditional SOC 2 approach is point-in-time: scramble for six weeks before the audit, collect evidence, get the report, relax for 11 months.
The problem is that Type II audits cover a full 12-month observation period. Auditors are not looking at your controls at the moment of the audit. They’re looking at whether you ran these controls consistently throughout the year.
If you manually provisioned access for the first eight months and only implemented SCIM in the two months before your audit, that’s visible in your log data. If you never did access reviews until the month before the audit, that’s a gap.
Continuous compliance means your IT operations are the compliance program. You don’t prepare for audits — you run the same systems year-round and the evidence accumulates automatically.
That’s the operational model Interlaced builds for clients: not compliance-as-project, but compliance-as-infrastructure.
HIPAA and Beyond
The same operational controls that satisfy SOC 2 CC6 largely satisfy HIPAA’s access control and audit controls requirements (45 CFR §164.312). If you’re in healthcare or handling PHI (Protected Health Information), the implementation details differ — particularly around minimum necessary access and business associate agreements — but the IT architecture is the same.
Our HIPAA compliance piece covers the specifics for healthcare-adjacent startups. For most SaaS companies, SOC 2 is the primary framework, and the controls above are the right starting point.
Frequently Asked Questions
How do I ensure IT compliance during onboarding and offboarding? Automate both from your HRIS. New hire activation triggers account provisioning via SCIM; termination triggers deprovisioning. Every event in this chain is logged in your IdP with timestamps. That log is your compliance evidence for CC6.2 without any additional documentation effort.
What compliance frameworks apply to IT operations? For most SaaS startups, SOC 2 Type II is the primary framework, covering security, availability, and confidentiality. Healthcare-adjacent companies also deal with HIPAA. Companies selling to enterprise customers or in regulated industries may encounter ISO 27001, FedRAMP, or GDPR-specific IT requirements. The IT controls that satisfy SOC 2 CC6 and CC7 largely carry over to these frameworks.
How do I maintain audit trails for access control? Your IdP’s admin log is your primary audit trail for user access events. Your cloud provider’s audit log (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) covers infrastructure access. Your MDM platform covers device compliance. Configure log retention to match your audit observation period — typically 12 months for SOC 2 Type II. Do not rely on individual app logs; aggregate at the IdP level.
What’s required for SOC 2 compliance in IT? At minimum: role-based access provisioning with documented process, timely deprovisioning with evidence, quarterly access reviews, MFA on all accounts (especially privileged), device enrollment in MDM, and logging of privileged actions. The controls don’t need to be elaborate — they need to be consistent, documented, and operating throughout the full observation period.
How do I prove access was revoked on time? Your IdP’s admin log shows the exact timestamp when a user account was deactivated. Your HRIS shows the employee’s termination date. The delta between those two timestamps is your evidence of how quickly access was revoked. With automated HRIS-to-IdP deprovisioning, that delta is typically minutes. Without automation, it’s days — which is a finding.
How do I prepare for a compliance audit? Stop thinking about audit prep as a pre-audit activity. The evidence for a Type II audit accumulates over 12 months. Build your IT operations so they generate evidence continuously: automate provisioning and deprovisioning, run quarterly access reviews on a fixed schedule, maintain MDM enrollment and compliance reporting, and log privileged access actions. When the audit request arrives, you’re pulling reports, not reconstructing history.
How do I automate compliance reporting? Your IdP, MDM, and cloud audit platforms all have export or reporting capabilities. Build a quarterly process to export the key reports (user provisioning events, group membership snapshots, device compliance status, access review logs) and store them in a compliance evidence folder. Tools like Vanta, Drata, or Secureframe can automate collection and formatting — but the underlying IT operations they pull from have to be configured correctly first.
How Interlaced Handles This For You
Building the IT operations layer that generates compliance evidence automatically — SCIM provisioning, HRIS-to-IdP automation, MDM enrollment, access review processes — is exactly what Interlaced implements for growing startups.
We’ve helped companies walk into SOC 2 audits with complete evidence packages because their IT operations were already running the controls. No pre-audit scramble. No reconstructed history.
If you’re 6-12 months out from a SOC 2 audit and want your IT infrastructure audit-ready before the observation period starts, that’s the right time to call.