Security

Real offensive depth

Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Compliance

What Is a SOC 2 Bridge Letter, and When Do You Need One?

Direct answer: A bridge letter, sometimes called a gap letter, is a short statement from your management covering the period between the end of your SOC 2 report and the date a customer is asking. It says that nothing material changed in your controls during that gap. You write it, not your auditor, and it is not an audited document.

Why the gap exists

A SOC 2 Type II report covers a defined observation window, say January to December. Your customer is reading it in March. They need something covering January to March, and the auditor will not have looked at that period yet. The bridge letter fills it.

What it can and cannot say

It can state the report period, the gap period, and that management is not aware of any material changes to the control environment or of any control failures during the gap. It can note changes that did occur, which is the part people leave out and should not.

It cannot provide assurance. No independent party has tested anything in the gap period, and any letter implying otherwise is misleading. Sophisticated reviewers know this and treat the letter as a statement of management intent, which is what it is.

Doing this for a deal? SOC 2 in 75 Days is our fixed-scope readiness track, with the price and the timeline published before you call us. See SOC 2 in 75 Days

Who signs it

Somebody who can actually speak for the control environment, usually the CTO, CISO or CEO. It is signed and dated on company letterhead. Auditors do not issue bridge letters, and a firm offering to write one on your behalf is not doing you a favour.

When it stops being enough

Bridge letters cover a few months. Once the gap runs past roughly three months, reviewers start pushing back, and past six months many will not accept one at all. If you find yourself writing long bridge letters, the underlying issue is that your observation window has drifted out of step with your sales cycle.

If material changes did happen in the gap, say so plainly and describe the change. A letter that says nothing changed, followed by a customer discovering a migration or a breach, is significantly worse than no letter.

If you are working out how your report period should line up with your renewals, that is part of what we scope in compliance readiness.

What a bridge letter should contain

Keep it to one page. Anything longer starts to read like an attempt at assurance, which it is not.

State the report period exactly as it appears in the report, then the gap period you are covering, then the date you are writing. Name the report type, because a reviewer filing this needs to know whether the underlying report was a Type I or a Type II. Confirm that management is not aware of any material changes to the control environment during the gap, and that no control failures came to management's attention. Then sign it, with a name and a title, from somebody who can actually speak for the company.

The part most companies omit is the disclosure of changes that did happen. If you migrated your identity provider, added a subprocessor handling customer data, or had an incident, say so, along with what you did about it. A letter that names two ordinary changes is more credible than one claiming nothing at all occurred across four months, because nothing at all occurring is not how companies work.

How long a gap you can reasonably cover

Three months is the common comfort limit. Some reviewers accept up to six. Beyond that, the letter stops carrying weight, because you are asserting a great deal about a period nobody examined.

If your gap is heading past six months, the honest fix is a shorter reporting cycle rather than a longer letter. A twelve month observation window with a report issued six weeks after it closes leaves a manageable gap. A window that keeps slipping produces gaps that no letter closes.

Who writes it, and who signs

You write it. Some audit firms will provide a template and a few will review the wording, but the letter is a management representation and the responsibility is yours. The signatory should be an executive, typically the CEO, CTO or whoever owns security. A letter signed by a compliance coordinator carries less weight with a reviewer who is deciding whether to accept it.

Before signing, somebody has to actually check. That means confirming the recurring controls ran through the gap period, that no incident went unreported, and that nothing changed in the environment that would have required disclosure. Signing without checking is how a management representation becomes a problem later.

When a reviewer will not accept one

Bridge letters fail in a few predictable situations. When the underlying report is a Type I, because a Type I describes a point in time and the letter is trying to extend a point rather than a period. When the report has significant exceptions, because the reviewer is being asked to accept a management statement about an environment the auditor already flagged. When the gap is long. And when the buyer is regulated in a way that requires independent assurance, in which case nothing you write yourself will satisfy them.

The reasonable response to any of those is not a better letter. It is a conversation about what the buyer actually needs and when your next report lands.

Practical handling

Write the letter once per gap period rather than per customer request. Date it at the start of the gap, refresh it monthly if the gap runs long, and keep the current version with your report so whoever fields security requests can send both together. Put it behind the same access process as the report itself, under NDA where that is your policy.

If you find yourself writing these constantly, that is a signal about your reporting cadence rather than about your letter template. Teams that keep their evidence current through the whole period, and therefore hold a predictable report date, spend far less time explaining gaps. That is the practical argument for treating the year between reports as the programme, which is what an ongoing retainer is for.

A template you can adapt

Structure beats prose here. A reviewer is scanning for four facts, and burying them in paragraphs makes the letter harder to accept, not more convincing.

Open by identifying the company and the report: the service organisation name, the report type, the audit firm, and the exact observation period. State the gap period with both dates. Then the representation itself, which is that management is not aware of any changes to the system or its controls that would materially affect the description of the system or the suitability of the design or operating effectiveness of the controls, and is not aware of any control failures, during the gap period. Then disclose specific changes, if any. Then sign, with name, title and date.

Two phrases matter. "Management is not aware of" is the correct standard, because it is what you can honestly assert. "No material changes" is the qualifier that keeps the letter true when ordinary changes occurred, which they always did.

What counts as a material change

This is where teams either over-disclose into uselessness or under-disclose into risk. A useful test: would a reasonable reviewer's assessment of your control environment change if they knew?

Things that generally qualify: a change of cloud provider or a major infrastructure migration, a new subprocessor with access to customer data, a change to your identity provider, a security incident involving customer data, a significant reduction in the team operating the controls, or the loss of the person named in the description as owning a control area.

Things that generally do not: routine hiring, ordinary feature releases, a new office, a change of accounting software, or vendor changes that never touch customer data. If you find yourself listing eleven items, the threshold is set too low and the letter stops communicating.

What buyers actually do with it

Understanding the other side helps you write a letter that gets accepted first time. On the buyer side, a security or vendor risk analyst has a file to complete and a recommendation to make. They need to demonstrate they considered the gap and were satisfied. A bridge letter is what lets them close that item.

What makes their job harder: a letter with no dates, a letter signed by someone with an ambiguous title, a letter that arrives three weeks after the request, or one that asserts nothing changed across a nine month gap. What makes it easy: a one-page letter, with the report attached, sent the same day, with the dates matching the report exactly.

The speed matters more than most companies realise. Procurement timelines die of a thousand small delays, and a two-week turnaround on a routine document is one of them.

Alternatives when a letter will not do

If the buyer will not accept a bridge letter, you have a few honest options. Ask your auditor whether an interim or short-period report is possible, which some firms will issue at a cost. Offer the underlying evidence for the gap period directly under NDA, which sophisticated buyers sometimes prefer anyway. Or shorten the gap by moving your observation window, which is a structural fix for a recurring problem rather than a fix for this deal.

What you should not do is have someone write a letter that implies independent testing occurred. That misrepresentation is far more damaging than the gap it was trying to paper over, and reviewers who catch it escalate.

Keeping the gap short in the first place

The teams that rarely need bridge letters are not better at writing them. Their reporting cadence is predictable because their evidence is current, so the window closes on the date they planned, fieldwork is short because the record is complete, and the report is issued weeks rather than months later.

That predictability compounds. Buyers stop asking about gaps. Renewals stop stalling on document requests. And the whole security review conversation shifts from explaining your compliance position to simply sending it, which is the outcome the programme is supposed to produce.

The evidence you should be able to produce behind the letter

A management representation is only as good as the check that preceded it, and most teams sign after a conversation rather than after a look. The look takes about an hour if the programme is running properly, and it is worth defining what it consists of.

Pull the recurring controls that fall inside the gap period and confirm each produced its artefact. If the gap runs January to March and your access review is quarterly, there should be a Q1 review record with a date inside the period. Check the joiner and leaver records against the HR list for the same window, because that is the gap where a departure gets missed. Confirm the vulnerability triage ran and that nothing critical is sitting open without an owner. Ask whoever runs infrastructure whether anything moved, and ask specifically rather than generally, because "did anything change" reliably produces "no" from people who migrated a database last month and do not think of it as a change to controls.

Keep that check as a short dated note alongside the signed letter. If a customer later discovers something you should have disclosed, the difference between a genuine oversight and a careless representation is whether you can show you looked.

The gap inside your own supply chain

Your report is not the only one with dates on it. If you carve out subservice organisations, and almost everybody does, your customers are relying on those vendors' reports as well, and those reports have their own periods and their own gaps.

Sophisticated reviewers notice this. If your report period ends in December and your primary hosting provider's ends in September, the reviewer following the chain properly has two gaps to close, and one of them is not yours to close. What you can do is know the dates, hold the current reports for your material subprocessors, and be able to answer without a week of chasing. A vendor register that records report type, period end, and next expected issue date for each material vendor turns that question from a fire drill into a lookup.

You cannot write a bridge letter covering a vendor's gap and should not try. What you can honestly represent is that you reviewed their most recent report including its exceptions and that nothing in your monitoring suggests a change. That is a different statement and should be worded as one.

When there is no report to bridge from

Two situations produce a request for a bridge letter where none is possible, and both are common enough to plan for.

The first is the company that has never had a report. A bridge letter extends an existing attestation forward, and with nothing behind it the letter asserts everything and evidences nothing. What works instead is being specific about the plan: the observation window you have committed to, the audit firm engaged, and the expected report date, backed by whatever interim evidence you will share under NDA. Buyers accept dated commitments more often than people expect, particularly when the commitment appears in the contract.

The second is the company moving from Type I to its first Type II. The Type I described control design at a point in time and said nothing about operation, so a letter stretching it across the following six months is asserting the one thing the underlying report never tested. Say what is true instead: the Type I date, the observation window currently running, its end date, and the expected report issuance.

Writing the disclosure when something did happen

The hardest version of this document is the one written after a real event in the gap period, and the instinct to write around it is exactly wrong.

Describe what happened, when it was detected, what the impact on customer data was including the honest answer if it was none, what you did, and what changed afterwards. Two or three sentences. Do not characterise the event as minor, because that judgement belongs to the reader and asserting it invites the opposite conclusion. Do not use language that implies an assessment nobody performed.

The same applies to structural changes. A change of cloud region, a new subprocessor, or the departure of the person named in the system description as owning a control area all belong in the letter with a sentence each about what replaced them. A letter naming a subprocessor addition and a departure, with the mitigation for each, reads as a company that watches its own environment. Silence followed by discovery reads as something else, and the reviewer who finds it escalates rather than asking.

What you are actually signing

Worth being clear about this, because the letter is short and casual-looking and is neither.

It is a signed representation from an officer of the company, made to induce a counterparty to proceed with a contract. Your customer agreements very likely contain a general representation about the accuracy of information you provide during security review. A knowingly false statement in a bridge letter is not a compliance problem, it is a contractual and potentially a personal one, and it will resurface during acquisition diligence when someone reads three years of them alongside the incident log.

That is the argument for the boring version of the letter. "Management is not aware of" is precise, defensible, and enough. Stronger language buys nothing with reviewers and costs you the ability to explain yourself later.

When you should not be paying anyone for this

Bridge letters are a one-page document and a one-hour check. If your programme is running, write it yourself, keep the wording stable year to year, and refresh the dates. Any firm charging meaningfully for one is charging you for a template.

The situation where outside help is genuinely worth it is different: you keep needing bridge letters because your report dates and your renewal dates never line up, or your last report carried exceptions and the letter is being asked to do work it cannot do. Both of those are structural, and both are fixed by moving the window or closing the exceptions rather than by improving the document. If that is where you are, the conversation to have is about the shape of the reporting cycle, and the year between reports is what an ongoing engagement is for. If the letter is the only thing between you and a signature, write it today and send it with the report attached.

Doing this for a deal? SOC 2 in 75 Days is our fixed-scope readiness track, with the price and the timeline published before you call us.

See SOC 2 in 75 DaysOr talk about a retainer

Before you go

Want the rest of this by email?

If this was useful, I send a few short notes on SOC 2 and compliance. Unsubscribe in one click, and replies reach me directly.

From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.

Want a second opinion on where you stand?

We run SOC 2, ISO 27001 and the rest of the compliance stack for startups and SMEs, and the security testing that sits behind it. The first call is free, and we will tell you if you are not ready to start yet.

Book a free call

Track record

Who is actually doing the work

5
Published CVEs, including a CVSS 9.1
76
Controls taken from nothing to a passed SOC 2 Type II
Zero
Exceptions on that Type II report
20+
Penetration testing engagements delivered

Published vulnerability research

Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.

A SOC 2 Type II built from nothing

At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.