You were audited a year ago and the product has changed a great deal since. A customer asks whether your newest service is covered. What do you tell them?

What was certified was a scope, not a company

The reflex answer to this question is to describe the controls: we encrypt in transit, we require independent approval on changes, the new service runs on the same platform as everything else, so of course it is covered. Every word of that can be true and the answer is still wrong, because the customer is not asking whether the controls are applied. They are asking whether an independent party examined this service and said so, and that is a question about a scope statement.

Both of the common assurance artefacts are bounded in the same two dimensions and it is worth separating them cleanly. A service auditor's report describes a defined system — named services, locations, supporting infrastructure and the people operating it — and, in the type that matters to most buyers, asserts that controls operated over a stated period. An accredited certificate attests to a management system whose scope is likewise written down: which parts of the organisation, which locations, which services. Neither is an adjective that attaches to your company name. So the answerable form of the customer's question is whether the service appears inside the scope statement, and whether the period they care about is one somebody examined.

The four ways scope falls behind the product

Scope drifts because it is set at an audit and the product changes continuously, and the specific routes are predictable enough to design against.

A new service is the obvious one. It was not running when the scope was agreed, so it is not in the description, however similar it is to what is. A new location or provider region is the one teams forget, because scope descriptions frequently name data centres or cloud regions and moving workloads to a new one puts them outside a boundary nobody thought of as a boundary. A new sub-processor sits underneath your system and inside your customer's interest, and where a report lists subservice organisations, adding one changes what the report describes. And an acquisition brings a team, an estate and possibly its own certificate, all of which sit outside your scope until deliberately brought in — which is slower and more disruptive than anyone plans for, because their change management now has to become yours.

What changed since the audit	Is it in scope	What you can honestly say
New service launched after the period	No	It is not in the current scope; here is when it will be, and here is our internal evidence meanwhile
Existing service, new region	Usually not, if regions are named	The controls are the same platform's; the region is not in the described system
New sub-processor	No	Named in our sub-processor list, not in the assurance artefact; here is their own report
Same service, period ended months ago	Systems yes, period no	Covered as described, with a gap since the period end that we can address separately
Acquired business unit	No	Out of scope; here is the plan and date for inclusion

The gap at the end of the period is its own question

Even for a service squarely inside scope, a report covering a period that ended some months ago says nothing about last month, and a sophisticated buyer will ask about exactly that. The customary answer is a letter from management stating that no material changes to the control environment occurred between the period end and the current date, commonly called a bridge or gap letter. It is worth knowing what it is and worth being straight about what it is: a management assertion, not an auditor's opinion, and therefore worth what your customer thinks your word is worth.

Where that is not enough, what closes the gap is your own continuous evidence — the dated, attributable artefacts your controls emit anyway — offered directly rather than through an auditor. That is a weaker form of assurance and a stronger form of transparency, and for a technical buyer it frequently lands better than a refusal.

Say the specific thing

The way to answer in the room is to state the boundary, then the plan, then the substitute. "The report covers these services for that period. The service you are asking about launched afterwards and is not in the described system. It runs on the same platform under the same change and access controls, and I can show you our own evidence for those. It comes into scope at our next audit, which begins in this month." Each of those sentences is checkable, which is what makes the whole answer credible.

The failure to avoid is the confident yes. A customer's security reviewer who accepts "yes, we are certified" and later reads a scope statement that does not mention the service has learned something about your assurance posture and something worse about you, and in a regulated buyer's process that discovery frequently escalates beyond the person you were talking to. The cost of the precise answer is a follow-up question. The cost of the loose one is your credibility on every other claim in the questionnaire.

Scope as a maintained artefact, not an audit deliverable

The engineering half of this answer is what stops the question being hard next year. Scope is usually written once, in a document owned by whoever managed the audit, and then diverges from reality silently. Tie it instead to something that already changes when the estate changes: a service catalogue entry, a tag in infrastructure code, a field in the deployment record. Then in-scope becomes a property of a service rather than a paragraph in a document, and the list of in-scope services becomes a query.

Two behaviours follow from that and both are worth mentioning. Launching a service can raise the question of scope at launch, when it is cheap to decide, rather than at the next audit, when it is a finding. And the difference between the catalogue and the last agreed scope statement is a report you can generate — which is precisely the list you need to answer a customer, and precisely the list your auditor will ask you to reconcile.

What certification does not tell your customer

Worth having ready, because interviewers push here to see whether you understand the instrument rather than just the process. Scope can be drawn narrowly and legitimately, so a valid artefact covering a peripheral system is not evidence about the system your customer will actually use. A report can carry noted exceptions, and a certificate can be held with open findings under a corrective action plan, so the existence of the artefact is not the same as a clean one. And responsibility does not transfer: assurance artefacts typically describe controls the customer is expected to operate at their end, so parts of the arrangement remain theirs no matter how thorough your audit was.

Which specific criteria, control identifiers or clauses are involved varies by framework and by version, and quoting one you have not checked in the current standard is exactly the error that costs you a compliance-literate audience. Describe the shape of the obligation, then offer to point at the section in the document you both have open.

A certificate or report covers named systems over a stated period, so the only honest answer names the boundary. Keep scope tied to the service catalogue and this becomes a lookup rather than a judgement call made under pressure in front of a customer.