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.

Evidence That Survives Sampling

A Type II examination tests a control at the level of a population, not an anecdote. For each control the assessor asks for the complete set of events in the period, every change merged to production, every account created, every access request approved, every restore tested, and then draws a sample from it. Sample size follows how often the control runs, so a control that fires daily yields a larger sample than one that fires quarterly. That reverses the usual instinct: the first question about a control is not whether you can show it happened once, but whether you can produce a dated, complete list of every time it should have happened.

Completeness and accuracy of that list is itself tested. A spreadsheet someone assembled by hand is not a population; an export from the system that performs the control, carrying record counts, timestamps and a filter you can state and re-run, is. This is the specific reason screenshots fail. A screenshot shows one instance, carries no evidence that it was drawn from a complete set, and usually omits who produced it and when. For every artifact you expect to hand over, be able to say which system it came from, what query produced it, and whether running that query again next quarter returns the same shape.

  • Change management: every merge into the branch that deploys, joined to the deployment records for the same period, not the changes someone recalls as significant.
  • Provisioning: every account created in the period in each in-scope system, including accounts created by automation rather than by a person.
  • Termination: the leaver list for the period joined against deprovisioning events, so the population comes from HR and the evidence comes from the identity provider.
  • Vulnerability management: every scan run in the period, plus the findings that aged past the remediation window your own policy commits to, since that is the number being compared against.
  • Incident response: every ticket meeting your written definition of a security incident, which means the definition has to exist before the period rather than be applied to it afterward.

ISO 27001 Certifies a Management System, Not a Control List

The certificate is issued against clauses 4 through 10 of the standard: context, leadership, planning, support, operation, performance evaluation and improvement. Annex A is a reference set you select from through risk treatment, not a list to implement wholesale, and the Statement of Applicability records every Annex A control with a justification for including or excluding it. The 2022 edition holds 93 controls in four themes, organizational, people, physical and technological, restructured from the 114 of the 2013 edition, and it introduced subjects that did not previously appear as their own controls, among them threat intelligence, information security for use of cloud services, and data masking. Transition from the 2013 edition has closed, so a current certificate is against the 2022 text.

Two clauses catch teams arriving from SOC 2. Internal audit, clause 9.2, and management review, clause 9.3, require records that already exist when the certification audit happens, so a management system stood up a month before the audit has no history to show. The audit comes in two stages: Stage 1 examines the documented system, the scope, the risk assessment, the Statement of Applicability and those records, and Stage 2 tests that it operates. Surveillance audits follow in the two years after certification, with recertification in the third.

Certification bodies are themselves accredited, so if a customer is going to file your certificate, confirm it carries an accreditation mark and that the scope statement printed on it describes the system your customer is asking about.

Your Cloud Provider's Report Does Not Cover You

A provider's SOC 2 report covers the provider's controls, and it names the controls it assumes you operate. Those are the complementary user entity controls, listed in the report as conditions attached to the opinion: configuring access and authentication in the service, managing your own keys, enabling and retaining logs, reviewing your own administrators. Your assessor reads that list and tests you against it, which makes a provider report an input to your scope rather than a substitute for part of it.

Read past the opinion page. The report states whether the opinion is unqualified or qualified, lists exceptions in the testing tables, and says how the provider treated its own subservice organizations. Under the carve-out method those subservice controls sit outside the report entirely, so if something you depend on lives there you need that party's report as well; under the inclusive method they are inside it. The vendor management evidence is the record that someone read all of this and reached a conclusion, not that a PDF was filed.

A vendor report covers a stated period and then stops, and your assessor cares whether you had current coverage across your own period. If the provider's period ends inside yours, the remainder is covered by the next report or by a bridge letter, which is the vendor's own management assertion that nothing material changed and is not itself audited. For a vendor with no report at all, what stands in its place is your diligence record: the questionnaire response, the security terms in the contract, and a dated decision by a named owner to accept the residual risk.

Where These Controls Land in the Pipeline

Change management criteria are satisfied by particular settings in the repository and the CI system, and it is worth naming them. Branch protection with required reviewers, required status checks and force-push disabled on the protected branch is what produces an approval record per change. Signed commits or signed tags bind a change to a verified identity. Deployment records bind a merge to what actually ran, which is the join an assessor asks for when the question is whether anything reached production without passing the checks.

The same settings answer more than one framework at once. In ISO 27002:2022 terms they map to 8.32 change management, 8.31 separation of development, test and production environments, 8.29 security testing in development and acceptance, 8.28 secure coding, and 8.25 secure development life cycle.

  • Whether the protected branch lets an administrator override a required review, and whether the override leaves a log entry.
  • Whether the security test job can be skipped by a commit message flag, a workflow condition or a manual approval, and whether skipping is recorded anywhere.
  • Whether production can be deployed from a workstation or a cloud console, outside the pipeline that produces the record.
  • Whether the artifact promoted to production is identified by an immutable digest or by a tag that can be repointed after the checks pass.
  • Whether service accounts and break-glass accounts are excluded from the reviewed population, and on what written basis.
  • Whether a reviewer's decision to revoke access produces an actual revocation event with a timestamp, rather than only a note that the review happened.

Frequently Asked Questions

What has to already exist before readiness work is worth starting?

Enough operational structure that controls can be attached to something. In practice that means one identity provider most access actually flows through, source control all production code passes through, a ticketing system where work is recorded, and a person with authority to decide things about production. Where those are missing, the first phase is building them, which is engineering work with its own schedule. A team still changing its architecture every few weeks can do the scope and risk work productively, but automating evidence against a moving target is effort spent twice.

What do you need from us to begin?

A description of the architecture and how data moves through it: which systems hold customer data, which of them are operated by someone else, and where data leaves your network. A vendor list that says what each vendor can reach rather than what each one costs. Named owners for access, infrastructure, onboarding and offboarding, and vendor decisions, because controls fail at ownership more often than at design. And the decisions only you can make, which are the boundary and the criteria or Annex A exclusions you intend to claim.

We already have a SOC 2 Type II. Does that answer a customer asking for NIST?

Usually not directly, because the artifacts differ in kind. SOC 2 is an attestation on controls against the trust services criteria; the NIST Cybersecurity Framework is a voluntary framework organized around the Govern, Identify, Protect, Detect, Respond and Recover functions, with no certificate or opinion attached to it. Much of the underlying evidence carries over, so a current-state assessment against the CSF can reuse populations and testing already produced for SOC 2. Where a federal clause is driving the request, it will name a specific publication such as SP 800-171.

What does a readiness engagement actually produce?

A gap list in which every gap carries a named owner and a decision, fix, accept, or move out of scope, rather than a severity label on its own. An evidence plan naming, for each control, the system of record, the export that produces the population, and how often it runs. For ISO 27001 it also produces the documented scope and boundary, the risk assessment and treatment, and a draft Statement of Applicability with a justification recorded against each control.

Who chooses the assessor, and when should they be brought in?

You choose them, and it pays to select one and start talking early, even though the examination window is booked at the end of the order described on this page. Two of their answers change work you would otherwise do twice: whether they accept your proposed boundary and criteria selection, and what form they want populations delivered in. Talking to a firm is not the same as booking a window, and the booking still belongs last, once the controls are operating and their evidence is automated. Assessor calendars fill, which is an argument for choosing early, not for opening an observation period before the controls are steady.

Do we need a compliance automation platform?

No, though one earns its place where it reads directly from the systems that perform the controls, an identity provider, cloud accounts, device management, source control, and produces populations you can reproduce. It does not help where it is pointed at a spreadsheet, or where a control has no system behind it to read. Treat its checks as its vendor's reading of a criterion rather than your assessor's, since a green dashboard is not a tested control and the underlying records get tested anyway. An agent installed on employee devices is also a scoping and privacy decision in its own right.

What is the difference between a Type I and a Type II, and which do we need?

A Type I opines on whether controls are suitably designed as of a single date. A Type II adds whether they operated effectively across a period, commonly three to twelve months, which is why populations and sampling enter the picture at all. Most customers asking for SOC 2 mean Type II; a Type I is a reasonable milestone when something has to exist before an observation window can have run. If you do both, watch the dates, because consecutive reports that leave a gap between periods create exactly the coverage question a reviewer will ask about.