Django SOC 2 Readiness Checklist

Problem statement

Enterprise customers increasingly ask SaaS vendors for a SOC 2 report before signing. SOC 2 is an audit against trust services criteria (security, and optionally availability, confidentiality, processing integrity, and privacy) of how you operate, not a certification of a framework. Auditors want evidence that controls exist and work over time: who can access production, how changes are reviewed and deployed, how incidents are detected and handled, and how data is protected and recovered. Much of that evidence comes from how a Django application is built and run. This checklist covers the technical side; policies, HR controls, and the audit process itself are beyond it.

1. Access: SSO with MFA for cloud, Git, CI, and admin tools; least privilege; quarterly access reviews; prompt offboarding.
2. Change management: all production changes through pull requests with review, automated tests, and a deploy pipeline with logs.
3. Logging and monitoring: centralised application and audit logs, alerting, and retention aligned with policy.
4. Data protection: TLS everywhere, encryption at rest, secrets in a manager, environment separation.
5. Availability: backups with regular restore tests, documented recovery objectives, incident response runbook.
6. Vulnerability management: dependency and image scanning, patching SLAs, periodic penetration tests; vendor risk reviews.

Checklist

Access control

• Production access (cloud console, database, servers, Kubernetes) through SSO with MFA; no shared accounts.
• Django admin and staff accounts per person, with 2FA and group-based permissions.
• Least privilege: developers do not have routine write access to production data; break-glass access is logged.
• Access reviews performed and recorded (quarterly is common); offboarding removes access within a defined time.

Change management

• Branch protection: pull requests with at least one reviewer, required CI checks, no direct pushes to main.
• Deploys happen only through the pipeline; deploy logs record who, what, and when.
• Database migrations reviewed (see the migration review checklist); emergency changes documented afterwards.
• Separate environments (development, staging, production) with production data not copied unanonymised.

Logging, monitoring, and audit trails

• Application logs, access logs, and infrastructure logs centralised with defined retention (often one year).
• Audit log of changes to sensitive data and admin actions, protected from tampering.
• Alerts for errors, availability, suspicious logins, and infrastructure issues, routed to an on-call rotation.
• Cloud audit logs (CloudTrail or equivalent) enabled and retained.

Data protection

• TLS for all external traffic and between services where data crosses networks; HSTS on.
• Encryption at rest for databases, backups, and object storage.
• Secrets in a secrets manager; rotation process documented; no secrets in code or images.
• Data classification and retention rules implemented (deletion jobs, customer data export and deletion).

Availability and recovery

• Automated backups with tested restores on a schedule, results recorded.
• Recovery time and recovery point objectives documented and consistent with backup and replication setup.
• Incident response runbook, communication plan, and post-incident reviews.
• Monitoring of capacity and uptime; status page for customers.

Vulnerability and vendor management

• Dependency scanning and container image scanning in CI with remediation timelines by severity.
• OS and runtime patching cadence; regular image rebuilds.
• Annual penetration test with findings tracked to closure.
• Subprocessors (cloud, email, payment, analytics) listed, with security reviews and DPAs.

Explanation

SOC 2 Type II examines whether controls operated effectively over a period, typically three to twelve months, so one-off fixes before an audit are not enough. For a Django SaaS, many controls map directly onto engineering practices: SSO and MFA for access, pull requests and CI/CD for change management, centralised logging and audit trails for monitoring, encryption and secret management for confidentiality, and tested backups for availability. Building these into the normal workflow produces the evidence auditors need as a by-product of daily work.

Edge cases / notes

• Scope the audit carefully: which systems, environments, and trust criteria are included.
• Small teams can meet controls with lightweight tooling; segregation of duties may rely on reviews and logs rather than separate teams.
• Compliance automation platforms (Vanta, Drata, Secureframe) integrate with cloud, Git, and identity providers to collect evidence.
• SOC 2 is not GDPR: privacy regulations have separate requirements, though many controls overlap.

Next steps

• Cover privacy obligations with the Django Privacy and GDPR Production Checklist.
• Build the audit trail with Keep an Audit Log of Changes in Django.

FAQ

Does Django itself need to be SOC 2 certified?

No. SOC 2 audits your organisation's controls; Django is part of the system those controls cover.

What technical controls matter most for SOC 2?

Access control with MFA, reviewed and logged changes, monitoring and audit logs, encryption, backups with restore tests, and vulnerability management.

What is the difference between SOC 2 Type I and Type II?

Type I assesses control design at a point in time; Type II assesses whether controls operated effectively over a period.

How long does SOC 2 readiness take?

Often several months to put controls in place, followed by an observation period for Type II.