The supplier you want cannot pass a policy written for someone else

Open the policy and find the sentence that triggers the requirement. In most organisations it is conditional — suppliers handling restricted data, or holding production credentials, or engaged above a spend threshold, must hold an independent certification. That conditional structure is the whole opportunity, because three of those four conditions are set by how you scope the engagement rather than by who the supplier is.

If the requirement really is unconditional and applies to every supplier regardless of what they touch, you are in a different situation, and the last section of this page covers it.

Read the trigger, not the headline

"Certified vendors only" is how the policy gets summarised in an email. It is rarely how the policy is written. Find the clause, read what it gates on, and check which of these four you are actually caught by.

The fourth column is the work. Each entry is a real change to the engagement, not a wording change, and each one costs something. That is the honest trade: you are buying an approval by reducing what the supplier can reach, and you should only do it where the reduced scope still produces something worth building.

The four routes that require nobody to lie

1. Take the data out of scope

The highest-yield move, because it deletes the clause rather than arguing with it. Most build work does not need production records — it needs data with the same shape, the same edge cases and the same volume distribution. Generating that deliberately is a solved problem and it doubles as test infrastructure you wanted anyway, which is the argument in can you generate your own test cases.

Be precise about what "masked" means before you claim it. Replacing names while leaving dates of birth, postcodes and a rare diagnosis in place does not de-identify anybody. If the supplier will process real personal data at any point, the classification stands and the honest route is a different one — and you should settle the processing roles in writing regardless, as set out in who is controller and who is processor on a build.

2. Remove production access from the engagement

Access granted on day 1 is the largest and least-reviewed exposure in most engagements, and it is usually granted broadly because narrowing it takes an afternoon nobody has — the pattern is set out in what a build team can reach inside your systems. Turning that around is what makes this route work: the supplier builds and tests against non-production, your team runs the deploy, and any live access is time-boxed, logged and approved per incident.

Security teams reject this proposal when it arrives as a paragraph and accept it when it arrives as an inventory. Count what the build actually touches by system, direction, entity and failure mode — the method in counting your integrations before asking for a number — and the review stops being a debate about trust and becomes a list with a decision against each line.

3. Restructure the commitment

Thresholds are real and they are usually delegated. A first engagement scoped as a bounded discovery or a single milestone frequently sits inside authority that a department head already holds, where a multi-year arrangement does not. This is not a trick — a smaller first commitment genuinely carries less risk, which is why the threshold exists. It also gives both sides evidence before anyone signs anything larger.

4. Use the documented risk-acceptance route

Nearly every policy that mandates certification also defines an exception process, and it is usually ignored because it requires somebody to put their name on a form. Do it properly and it works. A risk acceptance that gets approved has five parts: the specific control gap, the compensating controls, a named accountable owner at the right level, an expiry date, and the trigger that would force a review before then.

A certificate tells you a supplier had controls audited on a date. A scope that never gives them production data tells you what happens if the controls fail.

The order to do this in

Sequence matters, because the cheap moves make the expensive one unnecessary and the expensive one is a favour you can only ask once.

1. Get the policy text itself, not the summary in the rejection email. Ask for the clause number and read it as written.
2. Ask the reviewer one confirming question: which clause is blocking this, and what would have to be different for it not to apply? A reviewer who cannot answer is enforcing a convention rather than a policy, and that is a much easier conversation.
3. Try the scope levers in cost order. Data first, access second, commitment size third. Each one you can remove shrinks the exception you eventually need to nothing.
4. Only then submit a risk acceptance, for whatever gap actually remains after the scope changes. An acceptance covering 1 narrow residual risk gets signed; one covering "this supplier is uncertified" does not.
5. Put a review date on it. 6 or 12 months, tied to the engagement's next milestone, so the exception expires by design rather than becoming permanent by neglect.

What to send instead of a certificate

Reviewers need something to attach to the file. A small supplier can usually produce all of the following in under a week, and together they say more about current practice than an ISO 27001 certificate or a SOC 2 report covering a window that closed 11 months ago.

1. A written access model for the engagement. Which systems, which environments, which accounts, who approves, and how access ends. One page, specific.
2. The subprocessor list, including model providers. For an AI build this is the entry that matters most, because it names who else processes the content.
3. Answers to a right-sized questionnaire. A sub-50-person supplier answering the full enterprise set produces confident wrong answers; a trimmed set produces usable ones — see how to right-size a security questionnaire.
4. Evidence of practice rather than policy. Branch protection settings, Dependabot or equivalent scanning output, an offboarding record showing access revoked within 5 working days, a recent penetration-test remediation summary.
5. The architecture change you are proposing. The controls above, drawn as a diagram, with the trust boundary marked — the substance of buying safely from an uncertified supplier.

We are on the other side of this conversation often enough to state our own position plainly: BuildspaceLabs holds no security certifications, and our trust page says so rather than implying otherwise. What we can supply is the list above, and a scope designed so that the controls that matter are ones the client owns.

When there is genuinely no exception path

Sometimes the requirement is inherited rather than internal — a term flowed down from your own customer's contract, a regulated-sector expectation, or a rule your insurer set. In those cases nobody inside your organisation can grant an exception, because the obligation is not theirs to waive. Three options remain, in descending order of how well they usually work.

• Change what the engagement is. Advisory work, architecture review, a prototype on synthetic data or a bounded internal tool may fall outside the flowed-down term entirely. This is the route we most often take with clients whose policy blocks a full build — the shape described under MVP and product builds.
• Contract through a prime who genuinely takes accountability. Legitimate when the prime reviews the work, carries the liability and manages the access. Laundering when the prime is a pass-through that adds a badge and nothing else — and reviewers increasingly ask which one it is.
• Wait, and say so honestly. Certification takes months and costs real money. A supplier that has started the process can tell you the scope and the target date; one that has not should say that instead of implying otherwise.

The related diligence questions — what an audit report actually covers, where a prompt travels, and what a supplier's access really extends to — sit together in deciding what to build and who builds it, inside the wider library.

• procurement
• security
• vendor risk
• diligence