Deal blocked by a customer's security review: how to get unblocked

When an enterprise customer's security review blocks your deal, the way out is to turn a vague "security has concerns" into a short written list of specific blockers, then close each one with evidence, a fix, or a dated commitment the reviewer can accept. Most reviews stall on four or five items, not three hundred questionnaire rows, and the reviewer usually wants to say yes if you make it easy to defend that yes to their own risk committee.

This post is for the CTO, VP of Engineering or founder at a company that ships fast and has just hit its first, or worst, enterprise review. It covers why the review exists, what the reviewer is actually allowed to accept, a ten business day plan that works with whatever tools you have, templates you can copy, and then how Safeguard handles the same work. Nothing here is legal advice; your counsel should read any contract language before you sign it.

Key takeaways

• Ask for the blockers in writing. A security review that "has concerns" is not a task list. A named reviewer, a list of open items and a decision date are.
• Reviewers follow rules you can read. US banks follow the 2023 interagency third-party risk guidance, many financial companies follow the FTC Safeguards Rule's service provider clause, and New York regulated entities follow 23 NYCRR 500.11. Their questions trace back to those texts.
• Missing a SOC 2 report is rarely the real blocker. An honest status, a dated plan and evidence for the controls the reviewer cares about usually is enough to move forward with conditions.
• Their scanner found criticals in your product. Answer each finding with one of four statuses (fixed, not affected with a reason, fix scheduled with a date, accepted with a compensating control) and back each with evidence.
• Commit to dates you can hit. A remediation clause you miss in month two costs more than the deal you saved in week one.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis (SCA), vulnerability management with EPSS and KEV, reachability analysis, autonomous remediation with Griffin fix pull requests (ships switched off, every category set to Manual), policies and gates, CSAF and VEX upload, the Safeguard CLI and local runner, Portal (the SBOM publish and share product) and Trust Center.

The situation

The deal looked done. The champion loved the product, the pilot went well, legal had a redline in progress. Then procurement sent the vendor onboarding package and everything stopped. The email from your champion reads something like: "Our security team needs to finish their review before we can sign. They have a few questions."

The few questions turn out to be a long custom questionnaire, a request for your SOC 2 Type II report, a penetration test summary, a data flow diagram, a list of subprocessors and, increasingly, a software bill of materials. Sometimes the customer has also run their own scanner against your container image or your public web app and attached a spreadsheet of findings with forty "critical" rows.

Who is asking matters. The reviewer is usually a third-party risk analyst or a security engineer on the customer's vendor risk team. They do not own your deal; they own a risk rating for your company that they must defend to a manager, internal audit and, in regulated industries, an examiner. Your goal and theirs meet in one place: a file the reviewer can show their own auditor.

Your deadline is the end of your quarter. Theirs is a queue, and an incomplete response goes back to the bottom of it.

What a bad week looks like:

• You answer the questionnaire fast and optimistically, and a reviewer catches one answer that does not match the evidence. Now every answer is suspect.
• Your engineers argue with the customer's scanner output in a long email thread instead of answering finding by finding.
• Sales promises a SOC 2 Type II report "next month" when the observation period has not started.
• Someone agrees to a contract clause that requires all critical vulnerabilities fixed within 72 hours, across every dependency, forever.
• Nobody owns the review, so it waits for whoever has time.

The rest of this post is about avoiding that week.

Why the review exists: the rules behind the questions

Enterprise security reviews look arbitrary from the vendor side. They are not. Most large US buyers run them because a regulator, a framework or their audit committee requires them to manage third-party risk, and the questionnaire collects the evidence. Knowing the rule behind the customer tells you which questions are blockers and which are boilerplate.

Banks and bank holding companies

The Board of Governors of the Federal Reserve System, the FDIC and the OCC issued final Interagency Guidance on Third-Party Relationships: Risk Management, final as of 6 June 2023 and published in the Federal Register on 9 June 2023. It replaced each agency's older vendor guidance with one document and describes a life cycle: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination.

The due diligence section is the one your reviewer is working through. It lists factors a bank typically considers, from strategy and financial condition to information security, management of information systems, operational resilience, incident reporting, reliance on subcontractors and insurance. The information security factor is the one that produces most of your questionnaire. It describes assessing the third party's security program, controls that limit access to the bank's data such as multifactor authentication, end-to-end encryption and secure source code management, the software development life cycle, results of vulnerability and penetration tests, and whether the third party implements effective corrective actions for deficiencies found in testing.

Three points in the text help a young vendor:

• Scope follows risk. The guidance says the scope and degree of due diligence should be commensurate with the risk and complexity of the relationship. It is fair to ask which risk tier you are in and why.
• Missing information has a documented path. The guidance anticipates that a third party "may not have a long operational history" or may not share what the bank asks for. The bank is expected to document the limitation, understand the risk, and consider alternatives: obtain alternative information, add controls or monitoring, or choose a different provider. Your job is to make the first two options easy.
• Corrective action counts. Reviewers are told to look at whether you fix what testing finds. A dated remediation plan is evidence, not an admission.

Non-bank financial companies

The FTC's Standards for Safeguarding Customer Information, usually called the Safeguards Rule, covers a wide range of non-bank financial institutions: lenders, mortgage brokers, payment companies, tax preparers and others. Section 314.4(f) requires them to oversee service providers in three ways: take reasonable steps to select and retain providers capable of maintaining appropriate safeguards for the customer information at issue, require those safeguards by contract, and periodically assess providers based on the risk they present and the continued adequacy of their safeguards.

If your customer is covered by the Safeguards Rule, expect contract language that requires you to maintain safeguards, and expect a periodic reassessment. The initial review is only the first of several.

New York regulated entities

The New York Department of Financial Services cybersecurity regulation, 23 NYCRR Part 500, has a dedicated third party service provider section, 500.11. It requires covered entities to have written policies that address identification and risk assessment of providers, minimum cybersecurity practices those providers must meet, due diligence processes to evaluate the adequacy of their practices, and periodic assessment. The section also lists what the policies should address in guidelines, including access controls, encryption and notice of cybersecurity events.

That last item is why New York customers often push hard on breach notification timing in the contract.

Federal buyers and their suppliers

On the federal side the picture changed in 2026. OMB Memorandum M-26-05 rescinded M-22-18 and M-23-16, the memos that made the CISA Secure Software Development Attestation Form a government-wide requirement. Agencies are no longer required to collect it, but may still choose to use it, and may adopt contract terms that require a producer to provide a current SBOM on request. For a cloud platform, the memo's footnote says such a term should ask for an SBOM of the runtime production environment, which matters if you sell software as a service. NIST SP 800-218, the Secure Software Development Framework (SSDF), remains the reference for what secure development practice means. If you sell to an agency or to a prime contractor, expect SSDF language in the questionnaire even without the mandate.

Everyone else: frameworks the reviewer borrows

Companies outside those rules still run reviews, usually built on one of a few public frameworks. NIST SP 800-53 Revision 5 includes a control for exactly this, SR-6 Supplier Assessments and Reviews, which asks organizations to assess and review the supply chain risks associated with suppliers and what they provide. NIST SP 800-161 Revision 1 expands that into a full cybersecurity supply chain risk management practice. Many questionnaires are also built from shared industry templates, such as the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), which maps to its Cloud Controls Matrix.

The practical point: the reviewer is filling in a risk file whose shape comes from one of these documents. When you know which one, you can answer in its terms.

The questions that come from the SSDF

Because so many reviewers borrow SSDF wording for the software development section, it helps to know the tasks behind the most common questions:

Use the task ID only if the reviewer uses it first. The value is knowing what the question is really asking.

What "blocked" actually means

A blocked review usually comes down to a handful of categories. Name yours before you do anything else.

1. Missing artifact. They asked for a SOC 2 Type II report, a penetration test, or an SBOM, and you do not have one.
2. Unanswered or weak questionnaire rows. A set of answers came back as "partial", "no" or "not applicable" without explanation, and the reviewer cannot score them.
3. A finding. Their scanner, their penetration tester, or their review of your SBOM found vulnerabilities in your product.
4. A control gap. Something material is missing: no SSO for admin access, no audit logs, no encryption at rest for a data class they care about, no incident response plan.
5. A contract term. Security agreed in principle but legal will not sign until you accept a clause: breach notification within a set number of hours, a right to audit, remediation timelines by severity, data deletion on exit.

These need different responses. A missing artifact needs an honest status and a substitute. A weak row needs a better answer. A finding needs a disposition per finding. A control gap needs a fix or a dated plan. A contract term needs a decision by someone who can bind your company. Mixing them in one long email is how reviews stall for months.

Step by step: get unblocked in ten business days

The plan below assumes a small team, no dedicated security staff and no special tooling. Adjust the days to your situation, but keep the order.

Day 1: get the blocker list in writing

Ask your champion for a call with the reviewer, or at least a written list. You want four things:

1. The reviewer's name and role.
2. The risk tier they assigned you and the framework or policy they review against.
3. Every open item that prevents approval, separated from items that are informational.
4. The decision date and the internal meeting where the decision is made.

A short email works. Here is a template:

Subject: [Your company] security review: open items and decision date

Hi [reviewer],

Thank you for the review so far. So that we can respond completely
and in one pass, could you confirm:

1. The open items that are blocking approval, as opposed to items
   you are noting for the file.
2. The risk tier you have assigned and the standard you review
   against (for example your TPRM policy, SIG, CAIQ or SSDF).
3. Whether a conditional approval with dated remediation commitments
   is an option for any open item.
4. The date and forum where the decision will be made.

We will respond to every item in writing by [date], with evidence
attached and a named owner for anything still open.

[Name], [title]

The third question matters most. Many review processes allow approval with conditions or with an exception that the business owner signs. You need to know early whether that door exists.

Day 1: name one owner and one tracker

One person owns the review end to end. In a startup this is usually the CTO or a senior engineer, with sales operations supporting. They keep one tracker that holds every open item, its category, its owner, its evidence and its status. A spreadsheet is fine.

Use this blocker register:

The categories come from the section above. The "what we will send" column forces a decision for each item.

Day 2 and 3: triage the questionnaire

Go row by row and mark each as one of three states:

• Answered with evidence. You do it, and you can show it. Attach or link the evidence.
• Partial. You do some of it. Say exactly what you do and what you do not, and add a date for the rest if you plan it.
• Gap. You do not do it. Say so plainly, explain any compensating control, and give a date if you plan to close it.

Do not answer "yes" to anything you cannot show. Reviewers sample evidence, and one wrong "yes" damages every other answer. "No, and here is what we do instead" is a better answer than an unsupported "yes".

If the customer accepts standard questionnaires, ask whether they will take a completed CAIQ or a public trust page instead of their custom form for the rows that overlap. Many will, for at least part of the form.

For deeper treatment of answering rows honestly, see how to answer a security question when the honest answer is not yet and how to describe your SDLC in a security questionnaire.

Day 3 to 5: build the evidence pack

Put everything the reviewer might ask for in one folder with a short index. The usual contents:

On SOC 2: the AICPA's SOC 2 guide covers examinations of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. In common usage a Type 1 report addresses the design of controls as of a date, and a Type 2 report adds their operating effectiveness over a period. If you have neither, say where you are in that sequence and when the report will exist. Do not call a readiness assessment an audit.

Day 4 to 7: answer every finding

If the customer ran a scanner against your product, or their reviewer pulled your SBOM and found known vulnerabilities, answer each finding individually. Group them by component first, because forty findings often turn out to be six components.

Give each finding exactly one of these dispositions:

For prioritizing which to fix first, use public signals the reviewer also trusts. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation; anything on it should be fixed or credibly mitigated first. FIRST's Exploit Prediction Scoring System (EPSS) gives a daily estimate of the probability that a vulnerability will be exploited in the next 30 days. CVSS describes severity, not likelihood. A reviewer who sees you ranking by KEV, EPSS and reachability, not CVSS alone, sees a team that understands its own risk.

"Not affected" needs care. A VEX statement, as the OpenVEX specification defines it, is a claim by the supplier that a product is or is not affected by a specific vulnerability, with a justification such as "vulnerable code not present" or "vulnerable code not in execute path". It is only as good as the analysis behind it. If you cannot show why, say "under investigation" and give a date instead.

A finding response sheet the reviewer can sort:

Component | Version in image | CVE | Their severity | KEV | EPSS | Disposition | Detail | Evidence | Date
openssl   | 3.0.x            | ... | Critical       | no  | low  | Fixed       | Base image rebuilt | sbom-1.8.2.json | done
lib-a     | 2.1.0            | ... | High           | no  | low  | Not affected | Vulnerable function not called | analysis-lib-a.md | done
lib-b     | 4.4.1            | ... | Critical       | yes | high | Fix scheduled | Upgrade blocked by API change | PR link | Day 9

The rows above are illustrative. Fill in your own.

Day 5 to 8: fix what can be fixed this week

Some of the findings and gaps can be closed now. Do those first and say so, because a reviewer who sees movement during the review is more willing to approve with conditions.

Common quick wins:

• Rebuild container images on a current base image. Many container findings disappear.
• Upgrade dependencies with a non-breaking fixed version available.
• Turn on SSO and multi-factor authentication for administrative access to production and to your source code host.
• Turn on audit logging where it exists but is off.
• Publish a vulnerability disclosure policy and a security contact.
• Add a dependency check to CI so new known-vulnerable components cannot ship unnoticed.

Then regenerate the SBOM and rescan, so the evidence you send matches the release the customer will run.

Day 8 and 9: the remediation commitment

For anything still open, send a short written plan. Federal practice calls this a plan of action and milestones (POA&M); enterprise reviewers recognize the shape whatever you call it. For each item: what it is, what you will do, by when, who owns it, and what interim control applies until then.

Remediation plan: [Your company] for [Customer]
Prepared [date] by [owner, title]

Item 1: SOC 2 Type II report
  Plan:    Type II audit, security criteria, observation period
           [start] to [end]; auditor engaged [yes/no].
  Interim: Control evidence pack (index attached); Type I report
           expected [date] if applicable.
  Owner:   CTO

Item 2: lib-b critical vulnerability (KEV listed)
  Plan:    Upgrade to fixed version in release [x], target [date].
  Interim: [specific mitigation], verified by [how].
  Owner:   Platform lead

We will confirm completion of each item in writing within five
business days of its date, or tell you before the date if it moves.

Two rules for dates. Pick dates you would bet on, not dates that close the deal. And promise to notify before a date slips; reviewers forgive a moved date they heard about early far more readily than one they discover.

Day 9 and 10: settle the contract terms

Security clauses deserve the same attention as commercial ones. Before you accept any of these, know what they cost:

Remediation timeline clauses deserve special care. A clause that says "all critical vulnerabilities in the software will be remediated within 15 days" can be impossible to meet when no fix exists upstream. Propose language that ties the clock to exploitability and availability of a fix, and that recognizes a "not affected" determination. Your counsel should draft the final words.

Day 10: send one consolidated response

Send one response, not a stream: questionnaire, evidence index, finding response sheet, remediation plan and contract position. Offer a walkthrough, then follow up on the decision date you got on day 1.

What if we do not have SOC 2 yet?

This is the most common blocker for a fast-shipping company, and it is usually negotiable. The reviewer needs to show their file has reasonable assurance about your controls. A SOC 2 Type II report is one way to provide it. Others include a status letter with dates, a completed standard questionnaire with evidence, a penetration test summary, and a contract clause committing you to deliver the report when issued.

Be precise about where you are. "Audit in progress" means an auditor is engaged and an observation period has started. "Preparing for audit" means neither. A reviewer who later learns the difference will reopen everything.

If the customer requires a report before go-live, ask whether a Type 1 report is acceptable as an interim step, or whether they can approve for a limited data scope until the Type 2 is issued. Both are common.

What do we do when their scanner says we have criticals?

Do not argue with the tool. Answer each finding with a disposition and evidence, as above. Three patterns explain most disputed findings:

• Version mismatch. They scanned an older image or a public demo, not the release they will run. Send the current SBOM and scan for the actual release.
• Not present or not reachable. The vulnerable function is in a component you include but never call, or the vulnerable feature is compiled out. That is a "not affected" disposition, and it needs a justification.
• Operating system packages. Base image packages that your application never uses still show up. Rebuild on a smaller or current base where you can.

Be careful not to dismiss real findings as false positives. If a vulnerability is on the KEV catalog and your code path reaches it, it is a priority, whatever the deal timeline.

Should we send an SBOM?

Usually yes, under NDA, and increasingly the customer will require one. CISA, with NSA, the FBI and international partners, published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA minimum elements as the US reference for what an SBOM should contain. A reviewer who asks for an SBOM will often check it against that list.

Before sending one, validate it against the SPDX or CycloneDX specification, confirm it matches the release the customer will run, and decide how you will deliver updates. An SBOM shared once and never updated becomes a source of new findings with every CVE published.

For more on this question, see what an enterprise security review asks for.

How fast do we have to fix what they found?

There is no single legal answer for private contracts. What you commit to is what binds you. Public reference points help you set a defensible policy:

• CISA's Binding Operational Directive 26-04 (10 June 2026) revoked and superseded BOD 22-01 for federal civilian agencies. It sets remediation timelines in its Table 1 from four variables: whether the asset is publicly exposed, whether the CVE is on the KEV catalog, whether exploitation can be automated, and whether exploitation gives partial or total control. It does not apply to your company, but it is a good public model for timelines that depend on exploitability rather than a CVSS score alone.
• Your own policy is the main reference. Write timelines you meet today, publish them internally, and measure against them.

Whatever you choose, tie the timeline to exploitability and to fix availability, and keep a documented path for "not affected" and "no fix available".

Can a public trust page replace the questionnaire?

Partly. A trust page with your current framework status, policies, subprocessors and a way to request restricted documents under NDA answers many rows before anyone asks. Large customers still send their own questionnaire, but can often point to your page for the overlap. See the anatomy of a trust center for what reviewers look for.

How Safeguard does this

The steps above work with any toolset. This section shows how the same work maps to Safeguard, using only what Safeguard's docs describe. All capabilities named here are generally available (GA).

1. Build an accurate SBOM for the release the customer will run (SBOM generation and analysis, GA; SCA, GA). Connect your repository or container registry on the Integrations page, or scan locally with the Safeguard CLI (GA). The docs show the install and a local scan:

   # Install the CLI
   curl -fsSL https://cli.safeguard.sh/install | bash
   # Or scan from the command line, writing results under ./output
   safeguard scan --dir .
   

   The same command takes a container image or an existing SBOM instead of a directory. Scanning from the interactive terminal while signed in uploads the SBOM and findings to the platform; per the docs, your source never leaves the machine. For teams that will not grant repository access, the local runner (GA) keeps scanning on your own machines. Safeguard scans connected projects daily and can also scan on push, on a schedule or on release, so the SBOM you send stays current. We did not run these commands for this post; they are copied from docs.safeguard.sh.

2. Validate the SBOM before you send it (CLI, GA). The CLI's validate command checks CycloneDX, SPDX and VEX documents against their specifications:

   safeguard validate sbom.json --strict -o report.json
   

   A reviewer who opens a malformed SBOM will ask questions you do not need.

3. Rank the findings the way a reviewer would (vulnerability management with EPSS and KEV, GA; reachability analysis, GA). Safeguard's prioritization combines reachability, exploitability from EPSS and CISA KEV, runtime context and business context into one ranked backlog. The docs describe static, dynamic and configuration reachability, with each finding marked reachable, conditionally reachable or unreachable. That gives you the order for the finding response sheet: known exploited and reachable first. Reachability is evidence for a "not affected" disposition, not a substitute for your own judgment on it.

4. Open the fixes as pull requests (autonomous remediation with Griffin fix pull requests, GA). Where a fixed version exists, Griffin opens a tested, policy-gated pull request, for one repository or in bulk. Autonomous remediation ships switched off, with every category set to Manual, so your engineers decide what merges. Each merged fix becomes a "Fixed" row with a version and a new SBOM as evidence.

5. Record "not affected" determinations in a standard format (CSAF and VEX upload, GA). Safeguard accepts CSAF 2.0 and VEX documents in CycloneDX VEX, OpenVEX and CSAF VEX formats through Integrations, Upload CSAF/VEX. The docs describe using VEX uploads to mark vulnerabilities as not affected for your products, document mitigation status and reduce false positives in vulnerability reports. The justification still comes from your analysis.

6. Stop the same findings from coming back (policies and gates, GA). Create a policy on Settings, Policies, with conditions such as no critical CVEs or no vulnerabilities above a CVSS threshold, and attach it to a gate. Each policy's action decides what a failure does: Block fails the gate, Warn passes it with a warning, Notify passes it and sends a notification. When a legitimate exception is needed, a developer requests one with a business justification and an expiry date, and an approver decides; the decision is recorded in the audit trail. With policy outcomes switched on for your workspace, the docs show a CI job failing on a gate:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   That gives you an honest answer to "how do you prevent vulnerable components from shipping?", with the exception history as evidence.

7. Share the SBOM with access control (Portal, the SBOM publish and share product, GA). Portal sharing lets you send an SBOM to named recipients at a View, Download or Full permission level, or create a link with an expiry date, a download limit and password protection. At SBOM level you can require NDA acceptance and turn on download notifications, and you can revoke access at once. Tracking shows who accessed which SBOM and when. This is the free tier's namesake but a different thing: here "Portal" means the publish and share product.

8. Publish what reviewers ask for before they ask (Trust Center, GA). On Compliance, Trust Center you publish a public page at your own slug under trust.safeguard.sh with the frameworks you publish, control areas read live from continuous monitoring, policies, subprocessors, an FAQ, dated updates and documents. Each framework shows one status: Compliant, In progress, Not assessed or Signed. The docs are strict about honesty: a framework that needs an independent auditor cannot be shown as Compliant on a self-assessment, and the page says to "state only what is true today". Where a framework shows Not assessed, you can publish its live readiness score instead, which is the readiness of your own controls, not an audit.

9. Release restricted documents under NDA with an audit trail (Trust Center access requests, GA). With access management switched on, you mark documents such as a penetration test summary or an audit report as Restricted, publish an NDA, and turn on the access portal. A reviewer requests access, accepts the NDA and confirms their email; your team approves Full or Limited access with an end date, or an auto-approval rule decides, for example for existing customer domains. The NDA acceptance records the version, the typed name, the time, IP address and browser, and the agreement's SHA-256. The activity log exports to CSV. That replaces the "can you email us the pen test" thread with a record you can show.

What this looks like at the end of the ten days: an SBOM that matches the release, a finding response sheet backed by scan results, merged fix pull requests and VEX statements, a gate that keeps new known-vulnerable components out, a shared SBOM with access logged, and a trust page the reviewer can cite. Safeguard's own posture, if your reviewer asks about the tool: Safeguard's SOC 2 Type II audit is in progress, and the platform is designed for FedRAMP High.

What Safeguard does not do

• It does not answer your customer's questionnaire for you. Safeguard produces the evidence behind many rows: SBOMs, scan results, fix history, policy and exception records, trust page content. The answers, and their accuracy, remain yours.
• It does not make you SOC 2 compliant or issue a report. A SOC 2 report comes from an independent auditor, not from a tool. The Trust Center will show a framework as Compliant only on live readiness with every control passing, a current audit report or certificate, or a self-assessment where the framework allows it. It cannot turn readiness into an audit opinion.
• It does not decide "not affected" for you. Reachability analysis and VEX upload support the determination. The engineering judgment and the signature on it are yours, and a wrong VEX statement is a wrong statement to your customer.
• It does not negotiate or interpret contract terms. Breach notification windows, remediation clauses and audit rights are for your counsel and whoever can bind your company.
• It does not fix code it cannot change. Hosted services, vendor appliances and runtimes you do not build still depend on their own vendors. Autonomous remediation also ships switched off, so nothing changes until your team turns it on.
• It does not replace a penetration test. Scans and policy gates are evidence of process. A reviewer who asks for an independent penetration test usually still wants one.
• It does not shorten the reviewer's queue. A complete response helps, but the customer's process and timeline are theirs.

Common mistakes

• Answering before asking. Responding to a 300-row questionnaire without first learning which rows block approval. Ask on day 1.
• Optimistic "yes" answers. One unsupported claim, found during evidence sampling, costs more than ten honest gaps.
• Arguing with scanner output. Long emails about why a finding is wrong instead of a disposition with evidence.
• Sending a stale SBOM. An SBOM from three releases ago creates findings you have already fixed and hides ones you have not.
• Calling readiness an audit. "SOC 2 in progress" when no auditor is engaged and no observation period has started.
• Accepting impossible clauses. Fixed remediation windows for every vulnerability, regardless of whether a fix exists, or a promise of "no known vulnerabilities".
• No owner. Reviews without a single owner wait for whoever has time, which is nobody at quarter end.
• Solving this deal only. The next customer will ask the same things. Build the evidence pack and the trust page once, and keep them current.

FAQ

How long does an enterprise security review take?

It depends on the customer's risk tier for you and their queue. A low risk tool can clear in days; a system that touches regulated customer data can take weeks. A complete, honest first response shortens it more than anything else you control.

Can we get approved without a SOC 2 report?

Often yes, with conditions. Reviewers can usually approve with a status letter, evidence for key controls, a penetration test summary and a contract commitment to deliver the report when issued. Ask early whether conditional approval is possible.

What is the difference between SOC 2 Type 1 and Type 2?

In common usage a Type 1 report addresses the design of controls as of a date, and a Type 2 report adds operating effectiveness over a period. Reviewers usually prefer Type 2, but many accept Type 1 as an interim step.

The customer's scanner flagged critical vulnerabilities. What should we send back?

A finding response sheet with one disposition per finding (fixed, not affected, fix scheduled or accepted with compensating control), evidence for each, and dates for anything still open. Group by component first.

Should we share our SBOM with a prospect?

Usually yes, under NDA, for the release they will run, validated against the SPDX or CycloneDX specification. Agree how you will deliver updates.

What is a VEX statement and does the reviewer accept it?

A VEX statement says whether a product is affected by a specific vulnerability, with a justification. Reviewers accept them when the justification is specific and the analysis is available on request.

How do we answer "what are your vulnerability remediation timelines?"

With the timelines you meet today, by severity, and how you prioritize using KEV and EPSS. Do not copy a timeline from another company's policy that you have never measured yourself against.

Who should own the security review at a startup?

One named person, usually the CTO or a senior engineer, with sales operations helping on logistics. Legal joins for contract terms. Sales should not answer technical rows.

What happens after we are approved?

Periodic reassessment, usually annual, and contract obligations such as breach notice and SBOM delivery. Keep the evidence pack and trust page current so the next review is a refresh.

These steps get you through this review and the next one. Much of the work on day 4 to 8 is closing vulnerabilities in open source components you ship, and that is the part where waiting on an upstream maintainer can stall a commitment you already made.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix a lodash CVE in a repository. The CLI reads the finding and the advisory, asks before any command that changes something, edits package.json to the fixed version, runs the install and tests with approval, prints a summary and pushes nothing. For a blocked review, this is a "Fix scheduled" row turning into a "Fixed" row, with a person approving each change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. If your customer's reviewer asks how you scan without handing source code to another service, this is the flow to show: the scan runs on your machine and the SBOM and findings go to the platform.

Click through it at your own pace, or open it full screen.

Quick check

To build the evidence for your next review, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs.

Sources

• Federal Register (govinfo): Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR, 9 June 2023
• 16 CFR 314.4, Elements of the FTC Safeguards Rule (LII)
• 23 NYCRR 500.11, Third-party service provider security policy (LII)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (PDF)
• NIST SP 800-53 Rev. 5, Security and Privacy Controls
• NIST SP 800-53 Rev. 5 catalog, OSCAL content (SR-6)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• OMB Memorandum M-26-05 (PDF)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• AICPA: SOC 2 guide, Reporting on an Examination of Controls at a Service Organization
• Cloud Security Alliance: Cloud Controls Matrix and CAIQ
• OpenVEX specification
• Safeguard docs: Trust Center setup
• Safeguard docs: Trust Center access requests
• Safeguard docs: Portal sharing
• Safeguard docs: Generate SBOM
• Safeguard docs: Policies and Gates
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: CLI usage
• Safeguard docs: Vulnerability prioritization (reachability analysis)

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.