Continuous Controls Monitoring: From Annual Audit Panic to Always-On Compliance Evidence

A B2B marketplace connecting procurement teams with verified suppliers had made SOC 2 Type II a strategic priority after losing two enterprise deals where the information security questionnaire process stalled. The platform processed sensitive commercial data and handled supplier due diligence on behalf of enterprise buyers — SOC 2 was a commercial prerequisite, not just a compliance aspiration.

The Starting Point:

• SOC 2 Type I had been completed the prior year, revealing significant gaps in evidence quality for operational controls
• The engineering team had grown rapidly, introducing deployment process inconsistencies and access management gaps
• A previous Type II attempt had been abandoned after the auditor's initial evidence request revealed that the team could not produce consistent, timestamped evidence for access reviews, change management, and incident response over the audit period
• Security tooling existed (SIEM, vulnerability scanner, CI/CD pipeline) but logs and outputs were not being retained in an auditor-accessible format
• Access reviews were happening informally — no documented process, no records of who reviewed what and when

The platform needed a compliance posture that would:

• Continuously collect and retain evidence for all SOC 2 Security trust service criteria controls
• Automate access review execution and documentation on a quarterly cadence
• Produce a clean, queryable evidence library that auditors could self-serve from during fieldwork
• Surface compliance posture deviations in real time rather than discovering them at audit time
• Require minimal ongoing engineering effort after initial build — the team needed to maintain velocity on product work
• Support the full 12-month Type II audit period without evidence gaps

The technical challenge was that evidence for SOC 2 controls exists across many systems — CI/CD platforms, cloud providers, identity providers, ticketing systems, SIEM — and each system stores it in different formats, retains it for different periods, and requires different access for an auditor to retrieve it.

Evidence Fragmentation:

• Deployment approvals: in GitHub pull request history, accessible only to team members with repo access
• Access provisioning: in Okta and in a mix of GitHub teams, AWS IAM, and manual Notion pages
• Vulnerability management: in Snyk and AWS Inspector with no consolidated view or remediation SLA tracking
• Incident response: in Slack channels and ad-hoc Jira tickets — no consistent record structure
• Infrastructure configuration compliance: no continuous monitoring, assessed manually before each audit

Process Gaps:

• Access reviews: quarterly reviews were planned but not consistently executed or documented
• Change management: not all production changes had associated tickets; some were direct console changes without Terraform
• Vendor management: no formal process for reviewing third-party service access or BAA status

Audit Timeline Pressure:

The client had committed to enterprise prospects that a current SOC 2 Type II report would be available by a fixed date, creating a hard deadline that constrained the build timeline.

We designed a continuous controls monitoring system in three phases:

Phase 1: Evidence Collection Infrastructure (Weeks 1-4)

• Deployed a compliance evidence store: a purpose-built S3 bucket with Object Lock enabled, organised by control domain and collection date, with a lifecycle policy ensuring minimum 3-year retention
• Built automated evidence collectors (Lambda functions on daily/weekly schedules) pulling from:

- GitHub: PR merge records, branch protection configuration snapshots, required reviewer settings

- Okta: user provisioning events, MFA configuration, authentication logs, offboarding timestamps

- AWS: CloudTrail management events, Config compliance rule results, IAM policy snapshots, Security Hub findings

- Snyk: vulnerability scan results, open findings by severity, SLA breach alerts

- PagerDuty: incident records, response timelines, post-mortem links

• All collected evidence stored as structured JSON with collection timestamp, source system, and control mapping

Phase 2: Access Review Automation (Weeks 3-7)

• Built a quarterly access review workflow:

- Automated job generates a review package per system (AWS IAM, GitHub teams, Okta groups) listing current access holders and their role/justification

- Review package sent to designated reviewer via email with a structured review form

- Reviewer attests or flags each access record — responses stored in the evidence store with reviewer identity and timestamp

- Non-response after 5 days triggers escalation; unresolved flags trigger access removal after a further 48-hour grace period

• Evidence output: a dated, reviewer-attested access list per system for every quarter of the audit period

Phase 3: Continuous Compliance Monitoring and Alerting (Weeks 6-12)

• Deployed AWS Config managed rules for 40+ infrastructure compliance checks (encryption, public access, logging enabled, approved AMIs, required tags)
• Built a compliance posture dashboard (internal React app + Config aggregator data) showing pass/fail status per control in real time
• Drift detection: daily Terraform plan against production; non-empty diffs trigger a Slack alert and auto-create a Jira issue for triage
• Vulnerability SLA enforcement: Snyk webhooks trigger Jira issues on new critical/high findings with SLA due dates automatically populated; overdue issues escalate via PagerDuty
• Incident record standardisation: Jira template with required fields (timeline, affected systems, root cause, actions, review completed) enforced for all P1 and P2 incidents
• Evidence completeness check: weekly report showing control areas with coverage gaps (e.g. weeks with no incident records, quarters with incomplete access reviews)