SOC 2 and ISO 27001 Readiness for Engineering Teams

What SOC 2 and ISO 27001 are, and who audits them

Enterprise buyers ask SaaS vendors for one of two things during security review: a SOC 2 report or an ISO/IEC 27001 certificate. They are different instruments, so it helps to separate them.

SOC 2 is an attestation report. A licensed CPA firm examines your controls against the AICPA Trust Services Criteria: security (always included), and optionally availability, processing integrity, confidentiality and privacy. The output is a report your customers read under NDA. It is most common when selling into the United States.

ISO/IEC 27001 is a standard for an information security management system (ISMS). You define scope, assess risk, select controls (the standard’s Annex A is the reference set) and run the ISMS as an ongoing process. Certification is issued by an accredited certification body after an audit. It is widely recognised in Europe, the Middle East and Asia.

The two overlap on technical controls. Access management, change control, logging, backup and incident response appear in both. If you sell globally, one well-built engineering baseline can serve both, though the audit paperwork and the way scope is defined differ. See the compliance hub for how this fits with the other frameworks we cover.

We are an engineering consultancy. We are not a CPA firm or certification body, we hold no company-level certification, and nothing here is legal or audit advice.

What auditors actually test in engineering

Auditors do not test your architecture diagram. They pick samples and ask for proof. A typical sample request reads: “Show me five production changes from the period, with approval and test results.” If you cannot produce that quickly and consistently, you have a finding, even if the work was done well.

That is the central point of readiness: a control that works but leaves no evidence does not count. The engineering job is to make the correct behaviour the default path and to make that path leave a record.

How teams prepare, area by area

• Access reviews. Single sign-on in front of cloud consoles, roles granted to groups rather than individuals, no long-lived admin users, and a periodic review where someone with authority confirms who has what. The review itself is a process; we make the data easy to export.
• Change management through pull requests. Protected main branches, required reviews, required status checks, and deployments that run only from the pipeline. The pull request becomes the change record.
• Logging and monitoring. Cloud audit logs on in every account, retained in a locked-down location, plus application and cluster logs and alerts that reach a person. See monitoring with Grafana and Prometheus.
• Vulnerability management. Image and dependency scanning in the pipeline, infrastructure scanning before apply, and a defined way to triage and track findings to closure.
• Backup testing. Encrypted backups are not enough on their own. Auditors and ISO assessors like a recorded restore test. See backup and disaster recovery.
• Incident response. A documented process, an on-call rota, and at least one exercised scenario with notes. See SRE and incident response.
• Vendor management evidence. Knowing which suppliers touch your systems and data, and keeping their reports and agreements on file. The inventory is partly technical (which SaaS and cloud services are connected); the assessment is yours.

Mapping controls to evidence from pipelines and cloud logs

The table below shows how we typically connect a requirement area to a technical control and the artefact an auditor can sample. Exact criteria numbering and wording belong to your auditor; we keep to the area level.

A small example: a pipeline that leaves evidence

The point is not the specific job, but that scanning runs on every pull request and its result is stored with the run.

name: pr-checks
on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  iac-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan Terraform with Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: infra/
          output_format: sarif
          output_file_path: results.sarif
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: checkov-results
          path: results.sarif

Combined with branch protection that requires this check to pass, every merged change carries a reviewer, a passing scan and a log. Our guides to GitHub Actions, Terraform, Checkov and Trivy cover the tooling in more detail, and HashiCorp Vault is one option for secrets. Prometheus alerting supports the monitoring controls.

Type 1 versus Type 2 in plain terms

Type 1 asks: on this date, are your controls designed properly? The auditor reviews descriptions, configurations and a few examples. It is faster and is often used to unblock a deal.

Type 2 asks: over a period (commonly several months), did your controls actually operate? The auditor samples evidence from across the window. A branch protection rule turned off for three weeks, or a quarterly access review that was skipped, shows up.

For engineering teams the practical difference is this. For Type 1, you can fix a gap before the audit date. For Type 2, the gap is permanent once it occurs in the period, so the controls must be running reliably and evidence must be collected continuously from the start of the window. ISO 27001 has its own cycle of initial certification and surveillance audits, and the same principle holds: the system has to run, not just exist.

Typical pitfalls

Evidence gaps. The team does the right thing but in chat, in someone’s head, or in a tool nobody exports. Fix: decide the evidence source for each control up front and test that you can retrieve a sample.

Console changes. Someone fixes production by hand in the cloud console. The change is invisible to pull request history and may be overwritten by the next apply. Fix: move infrastructure to code, restrict console write access, and alert on out-of-band changes. This is the same journey described in from ClickOps to Terraform on AWS and in our Terraform infrastructure as code service.

Shared accounts. A shared admin login or a shared deploy key means you cannot show who did what. Fix: individual identities through SSO, short-lived credentials for pipelines, and break-glass access that is logged and reviewed.

Controls that exist only on paper. A policy says critical vulnerabilities are fixed in a set time, but nothing tracks it. Fix: tie scanner findings to tickets so the trail exists.

Scope drift. New accounts, clusters or SaaS tools appear and nobody adds them to scope. Fix: build new environments from the same modules and baseline, so they arrive with logging and access controls in place.

Who does what

What we do not do

• We do not certify, audit or attest, and we cannot say that using our services makes you compliant.
• We do not write your security policies, run your risk assessment or act as your ISMS manager. Those belong to you or a specialist adviser.
• We do not give legal advice or interpret contract terms placed on you by customers.
• We do not replace the auditor’s judgement on whether a control is adequate.

When to hire someone else

If you have no security owner, no policies and no sense of scope, start with a compliance specialist or virtual CISO and bring us in for the technical build. If a customer contract raises legal questions, speak to a lawyer. If your platform vendor needs to choose between SOC 2 and ISO 27001, your sales team and prospective auditor can usually say which one buyers are asking for.

Common misunderstandings

• “A tool makes us compliant.” Tools collect and organise evidence. People still run the controls.
• “SOC 2 is a certification.” It is an attestation report, not a certificate. ISO 27001 is the one that is certified.
• “We can fix it all before the audit.” True for Type 1 design gaps, not for Type 2 operating gaps.
• “More tooling means better results.” A small set of consistent controls beats a large set that nobody maintains.

How we engage

Most clients begin with a Cloud DevOps Health Check to find the gaps, then use a landing zone sprint for account structure and baseline logging, a CI/CD rebuild for pull request controls, or an observability and on-call setup for monitoring and incident handling. Kubernetes teams may add the EKS production readiness review. Ongoing operations can run under managed DevOps plans.

If you are also preparing for European or financial-sector requirements, see GDPR and EU data residency, NIS2 technical controls and DORA ICT third-party risk. Our own working standards are in the Trust Center. To talk through your audit timeline, contact us.

References

• System and Organization Controls: SOC Suite of Services, AICPA and CIMA
• About protected branches, GitHub Docs
• What Is AWS CloudTrail?, AWS documentation