Security Compliance Readiness

Most compliance programmes fail the same way: the controls are written to satisfy an auditor rather than to secure anything, evidence is assembled frantically in the weeks before assessment, and the whole exercise repeats a year later having improved nothing.

Compliance readiness done properly means implementing controls that genuinely reduce risk, and generating evidence as a by-product of operating them.

What We Support

  • SOC 2 — readiness assessment, control design and evidence workflow ahead of a Type I or Type II.
  • ISO 27001 — ISMS scoping, risk assessment and control implementation.
  • NIST CSF — current-state assessment and prioritised improvement roadmap.
  • Customer security questionnaires — the ones blocking your enterprise deals right now.
  • Secure SDLC evidence — connecting requirements, threat models, tests and approvals. See DevSecOps.

Evidence Should Be a By-Product

If your pipeline enforces review, runs security tests and records approvals, the evidence already exists — it just needs collecting. That is the difference between a compliance programme that costs a fortnight a year and one that consumes a quarter. It is also why we approach readiness as an engineering problem rather than a documentation exercise.

We Will Tell You What Compliance Does Not Cover

A SOC 2 report is not a statement that you are secure; it is a statement that specified controls operated over a period. Plenty of breached organisations were compliant. We will help you pass, and we will be clear about which real risks the framework does not address — because you should know that even when the auditor does not ask.

Tell us which framework or questionnaire you are facing and by when, and we will assess the gap honestly.

Related services

Which Framework Do You Actually Need?

Let the requirement come from the document that names it: a customer’s security review, a regulator’s rule, or a procurement questionnaire sitting in someone’s inbox. If your buyers are United States enterprises, ask which of them will accept SOC 2 and at which trust services criteria. If you are selling into international or public sector procurement, ask whether ISO 27001 is the certificate they want to see in the file. If you sit in a federal supply chain, the obligation is written into a specific contract clause naming a specific regime, so get the clause and read it instead of assuming that NIST in general is the answer. If nobody has asked and no regulation applies, certification may be premature, and the same effort spent on access control, logging and backup testing will do more for your real risk. That is worth saying out loud early, before a program gets built around a requirement no customer has actually raised.

Scope Is the Decision That Costs You Later

The system boundary determines nearly everything downstream: which environments produce evidence, which staff fall in scope for training and background checks, which vendors become subservice organizations, and how much of the estate has to hold still while you are assessed. A narrow boundary is easier to defend and quicker to reach. It also risks producing a report that does not answer the question your customer asked, at which point the exercise repeats with a wider scope. Deciding this deliberately, with the customer’s actual question in front of you, is time well spent.

We Prepare You. We Do Not Audit You.

The firm that helps design and implement controls cannot also issue the opinion on them, and that separation is the entire point of an assessment. Our part is readiness assessment, control design, remediation and evidence workflow. A licensed CPA firm performs the SOC 2 examination. An accredited certification body performs the ISO 27001 audit. We will help you brief them and respond to their findings, and we issue no certificates or attestations of any kind. Our secure software development page states the same limit for code review, for the same reason: the party that builds or remediates a thing is not the party that should assure it.

The Year Two Problem

First certification is a project with a deadline and everyone’s attention. The second cycle has neither, and that is where a program can quietly come apart. Controls decay because the person who owned them changed roles, evidence collection reverts to manual screenshots, and scope drifts as the product grows. The durable fix is to make evidence fall out of systems that would run anyway: pipeline approvals, ticket history, identity provider reports, backup job output, access reviews performed in the tool that grants access. A control that produces its own record is one you are not rebuilding every year.

Questionnaires Are a Different Animal

Customer security questionnaires arrive with their own vocabulary and frequently ask about things no framework covers, such as subprocessor lists, AI and model usage, data deletion timelines, or where your engineers are located. Two things help. Keep a maintained answer library with named owners and review dates. And be willing to answer that something is not implemented when that is the truth, with a dated plan attached. How a reviewer prices a disclosed gap is outside your control and outside ours. What you can control is whether an answer survives being checked, because the answers that do not are the ones that cause trouble after a contract is signed.

An Order That Holds Up

Teams get stuck trying to do policy, tooling and evidence simultaneously. A workable order: agree the boundary, run a gap assessment against the chosen framework, fix the control gaps that also reduce real risk, automate evidence for the controls you will be asked to demonstrate over and over, then book the assessment window. Policy documents get written along the way to describe what you actually do. The order matters, because policy written first becomes a careful description of a system nobody has built yet.