Security compliance checklist for engineering teams
Which standards apply to you?
GDPR
- Scope
- Personal data of EU residents
- Who needs it
- Any org processing EU data
SOC 2
- Scope
- Service organization controls
- Who needs it
- SaaS & cloud service providers
ISO 27001
- Scope
- Information security management
- Who needs it
- Enterprise & government vendors
PCI DSS 4.0
- Scope
- Payment card data protection
- Who needs it
- Anyone handling card payments
HIPAA
- Scope
- Protected health information
- Who needs it
- Healthcare & health-tech
DPDPA
- Scope
- India's data protection law
- Who needs it
- Orgs processing Indian citizen data
20 controls every engineering team should implement
Access Control
Data Protection
Application Security
Infrastructure & Operations
Compliance misconceptions that hurt engineering teams
Myth: “Compliance equals security”
Compliance is the floor, not the ceiling. You can be compliant and still vulnerable.
Myth: “It's an auditor's problem”
Engineers own the controls. Auditors verify them. Build compliance into your workflow.
Myth: “You need to do everything at once”
Start with the framework your customers require. Expand from there.
Myth: “Compliance slows down delivery”
Automated controls in CI/CD actually speed up delivery by catching issues early.
A practical audit preparation workflow
Phase 1: Evidence inventory (12 weeks before audit)
Start by mapping every control in your target framework to a specific piece of evidence. For SOC 2, this means documenting who owns each Trust Services Criterion, where the evidence lives, and how often it refreshes. Build a shared spreadsheet or use a GRC tool like Vanta, Drata, or Sprinto. The goal is zero surprises — every control should have an owner, a data source, and a refresh cadence before the auditor arrives.
Phase 2: Gap remediation (8 weeks before audit)
Run an internal pre-audit against your evidence inventory. Flag every control where evidence is missing, stale, or manually maintained. Prioritize gaps by audit risk: controls that auditors always scrutinize (access reviews, change management, incident response) get fixed first. Common gaps we see at this stage include quarterly access reviews that were never actually performed, change management logs that exist in Jira but lack approval timestamps, and backup restoration tests that were documented but never executed.
Phase 3: Evidence collection automation (4 weeks before audit)
Automate evidence collection wherever possible. Pull access review logs directly from your IdP. Export change management records from your CI/CD pipeline. Generate infrastructure configuration snapshots from Terraform state. The more evidence you can produce programmatically, the less time you spend chasing screenshots and the more defensible your controls become. Auditors trust automated evidence far more than manual documentation.
Phase 4: Dry run (2 weeks before audit)
Conduct an internal walkthrough where control owners present their evidence exactly as they would to an auditor. This exposes explanatory gaps — situations where the evidence exists but the narrative connecting it to the control is weak. Have someone unfamiliar with the control play the auditor role and ask clarifying questions. Fix any issues surfaced here. This single step eliminates the majority of audit findings.
Automated compliance scanning: what to look for
There are three categories of scanning tools every compliance-conscious engineering team needs. First, static analysis and policy-as-code tools like Open Policy Agent (OPA), Checkov, and tfsec that validate infrastructure configurations against compliance rules before deployment. These catch issues like unencrypted S3 buckets, overly permissive security groups, and missing logging configurations at the Terraform plan stage, not after resources are provisioned.
Second, runtime compliance monitoring tools like AWS Config Rules, Azure Policy, or cloud-agnostic solutions like Prisma Cloud and Wiz. These continuously evaluate your deployed infrastructure against compliance benchmarks (CIS, NIST, PCI DSS) and alert on drift. The key differentiator between tools here is remediation capability — some only alert, while others can auto-remediate by reverting non-compliant configurations to their approved state.
Third, dependency and container scanning tools like Snyk, Trivy, and Grype that audit your software supply chain. For PCI DSS 4.0 compliance, you need to demonstrate that every third-party component in your payment processing path is tracked, assessed for vulnerabilities, and patched within defined SLAs. Container scanning is particularly important — base images often contain hundreds of packages, and a single unpatched CVE can become an audit finding.
When evaluating tools, prioritize integration depth over feature count. A scanner that runs automatically on every pull request and blocks merges on policy violations is worth more than a comprehensive dashboard that engineers check once a quarter. The best compliance tooling is invisible to developers until it catches something — it fits into existing workflows rather than creating new ones.
Common compliance gaps in microservices architectures
Service-to-service authentication gaps
In a monolith, internal function calls do not cross trust boundaries. In microservices, every inter-service call is a network request that an attacker could intercept or forge. Many teams implement mTLS at the ingress layer but leave east-west traffic between services unauthenticated. For SOC 2 and ISO 27001, you need to demonstrate that service identities are verified on every call. Service meshes like Istio or Linkerd solve this with automatic mTLS, but they add operational complexity. At minimum, implement mutual TLS between all services and rotate certificates automatically.
Distributed logging and audit trails
Compliance frameworks require complete audit trails for sensitive operations. In a microservices architecture, a single user action can trigger calls across five or ten services. Without distributed tracing and correlated logging, you cannot reconstruct the full sequence of events for an auditor. Implement correlation IDs that propagate across every service boundary, centralize logs in an immutable store, and ensure that every service logs the authenticated identity performing each operation. OpenTelemetry provides a vendor-neutral way to instrument this, but the key is making it mandatory — a service that does not propagate trace context should fail code review.
Data residency in distributed systems
GDPR and India's DPDPA impose data residency requirements that are straightforward in a monolith with a single database but become complex when data is replicated across services. If your user service stores PII and three downstream services cache portions of it, you need data flow maps that document every location where personal data resides, how long it is retained, and how deletion requests propagate. Build data lineage documentation as part of your service registry and update it during architecture reviews.
Secrets sprawl across services
Each microservice needs credentials for its dependencies — database passwords, API keys, encryption keys, and service account tokens. Without a centralized secrets management strategy, these credentials end up in environment variables, config files, and container images where they are difficult to rotate and easy to leak. Use a secrets manager like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Enforce short-lived credentials where possible, rotate long-lived secrets on a defined schedule, and audit secret access logs to detect anomalies.
Incident response documentation that satisfies auditors
Your incident response plan needs five documented components that auditors will verify. First, a classification matrix that defines severity levels with specific, measurable criteria — not vague descriptions like “major impact” but concrete thresholds such as “any unauthorized access to PII affecting more than 100 records is Severity 1.” Second, escalation procedures with named roles (not individuals) and maximum response times for each severity level. Third, communication templates for internal stakeholders, affected customers, and regulatory bodies — GDPR requires notification to supervisory authorities within 72 hours, and you cannot draft that notification for the first time during an active breach.
Fourth, evidence preservation procedures that specify how to capture forensic data without contaminating it. This includes log retention policies, memory dump procedures, and chain of custody documentation. Engineers often destroy evidence unintentionally by restarting services or redeploying during incident response. Your plan should explicitly state what to preserve before any remediation actions begin. Fifth, post-incident review requirements including root cause analysis methodology, corrective action tracking, and lessons-learned distribution. Auditors want to see that incidents lead to systemic improvements, not just immediate fixes.
The most critical element auditors assess is evidence of testing. A beautifully documented plan that has never been exercised is a compliance risk, not a compliance control. Run tabletop exercises quarterly where you walk through realistic scenarios — a ransomware attack, a data breach notification, a compromised service account — and document the outcomes. Track action items from these exercises the same way you track production incidents. The exercise records themselves become audit evidence that your incident response capability is operational, not theoretical.