{/* Schema recommendation: BlogPosting + FAQPage.
- BlogPosting: author Nalin Vahil, datePublished and dateModified 2026-09-11. Emitted by the post template from frontmatter.
- FAQPage: emitted from the frontmatter faq block. Do not duplicate the FAQ in the body; the template renders it below the article.
- Table candidates for rich extraction: the risk-category table, the six-failure-mode table, and the per-agency scoring table -- semantic markdown tables, no dedicated schema type needed beyond standard Table markup.
- BreadcrumbList: Home > Blog > The SBIR Technical Risk Section (final crumb URL must be /post/sbir-technical-risk-declaration-framework, not /insights/). Internal linking: first Specific Aims mention links to /post/sbir-significance-opener-framework (same Specific Aims page, same reviewer-feedback theme); CTA links to https://www.getcada.com/book. */}
Most founders draft their SBIR Specific Aims to sound as confident as possible. Every sentence promises success. Nothing sounds uncertain.
That instinct is backwards, and it costs points.
One external reviewer evaluating a Cada-drafted NASA SBIR proposal put it bluntly: "The writing reads more as engineering than R&D... There appear to be no technical risks from the writing at all." That comment came back on a proposal with strong technical content. The problem wasn't the science. It was that the draft never admitted anything could go wrong.
A credible SBIR technical risk section names at least one specific, science-or-engineering-level risk per Aim (not schedule or personnel), pairs it with a mitigation that names an action and a trigger threshold, and ideally adds an independent fallback path. Skipping this makes even a strong proposal read as routine engineering instead of the R&D federal reviewers are funding.
What counts as a "technical" risk (and what doesn't)
Federal reviewers use "technical risk" narrowly. It means a risk to the science, engineering, biology, chemistry, algorithm, or measurement in your project. It does not mean anything about your calendar, your team, or your vendors.
| Category | What it covers |
|---|---|
| Material / chemistry | A material or reaction might not behave as expected under your operating conditions |
| Biology | An organism, cell line, or biological process might not respond as predicted |
| Algorithm | A model or classifier might not generalize to your real-world data |
| Hardware integration | Components that work alone might not work together at the required tolerance |
| Measurement / verification | Your test method itself might not be reliable enough to prove the result |
| First-time integration | You're combining two things that have never been paired before, and the pairing itself is unproven |
None of these are the same as "our subcontractor might be late" or "our PI travels a lot." Those are real project risks. They are not technical risks, and reviewers do not credit them as such.
Cada's internal reviews of client Specific Aims turn up the same pattern again and again: founders list "delayed procurement" or "key personnel availability" as their one risk, then move on. A reviewer scoring the Approach criterion reads that and concludes you haven't thought hard enough about your own science.
The three-part credibility test
A technical risk statement earns reviewer credit when it clears three bars.
- Named risk. State the specific mechanism that might fail, not a category. "The coating may fail" is a claim. "The anti-corrosion coating may lose adhesion strength below 2 MPa after 500 hours of salt-fog exposure" is a named risk.
- Credible mitigation. Name the action you will take and the threshold that triggers it. "We will monitor and adjust" is not credible. "We run salt-fog testing at month 3, and if adhesion falls below the 2 MPa threshold, we switch to a surface-primer step already validated in bench trials" is.
- Independent fallback (preferred). If the mitigation itself fails, is there a second, unrelated path to the same result? A fallback that depends on the same assumption as the mitigation doesn't count as independent.
The fallback is the strongest signal you can send. It tells a reviewer you've thought two moves ahead, not one.
Six ways founders get this wrong
| Failure mode | What it looks like | What a reviewer concludes |
|---|---|---|
| Risk-free framing | Every Aim ends in confident success language, no risk mentioned | This reads as engineering, not research |
| Schedule-only risk | "Risk: subcontractor onboarding may be delayed" | You haven't examined your own science |
| Personnel-only risk | "Risk: PI's time is constrained" | Same conclusion, different excuse |
| Vague mitigation | "Mitigation: we will address this if it arises" | No real contingency plan exists |
| Missing fallback | One mitigation path, no backup | Weaker than it needs to be, but survivable |
| Risk-register theater | A risk register lists the risk, but the Aim narrative never mentions it | You padded a document instead of doing the analysis |
The first three are outright disqualifying for a rigorous reviewer. The last three are weaknesses that a sharp reviewer will note but that don't automatically sink the section.
Worked examples across five agencies
These scenarios are fully fictional, built to show the pattern, not drawn from any real client project.
NIH SBIR (biology). A company developing a saliva-based inflammatory marker test writes: "Cytokine concentration in saliva may fall below our assay's 2 pg/mL detection floor in a subset of patients. We validate detection limits against paired serum samples in the first 20 enrolled subjects, and if more than 15% fall below the floor, we switch to a pre-concentration step already validated in our preliminary data. As an independent fallback, a second biomarker panel targeting a distinct inflammatory pathway is available if the primary marker underperforms across the cohort."
NASA SBIR (hardware integration). A company building a compact regolith sample handler writes: "The vibration-dampened gripper has never been paired with our lightweight actuator; the combination may introduce resonance above our 50-micron positioning tolerance. We run bench-level vibration testing at month 3, and if resonance exceeds tolerance, we add a passive damping collar already sized in our design. If damping is insufficient, we fall back to a slower actuation profile that trades cycle time for positioning accuracy."
NSF Pitch (algorithm). A company building a defect-detection model for injection-molded parts writes: "Our classifier, trained on 5,000 lab-generated defect images, may not generalize to the visual noise of a live factory floor. We benchmark against 200 factory-floor images at month 2, and if accuracy drops below 85%, we retrain with a factory-floor-specific augmentation set. As a fallback, a human-in-the-loop review step catches misclassifications above a confidence threshold until the model is retrained."
ARPA-E (material / chemistry). A company developing a low-cost solid electrolyte writes: "Ionic conductivity may drop below our 1 mS/cm target at the reduced sintering temperature required for cost targets. We test three sintering profiles at month 4, and if none clears the threshold, we introduce a dopant already shown in the literature to improve conductivity at lower temperatures. If the dopant path fails, an independent fallback uses a thinner electrolyte layer to offset lower conductivity, at a manufacturing cost still below our target."
AFWERX (first-time integration). A company pairing an existing radar processor with a new low-cost antenna array writes: "This is the first known pairing of our processor's beamforming algorithm with this antenna geometry, and signal-to-noise ratio may fall below the 10 dB threshold needed for reliable detection. We run anechoic-chamber testing at month 2, and if SNR falls short, we adjust the beamforming weights already parameterized for antenna geometry changes. As an independent fallback, the processor supports a wider bandwidth mode that recovers SNR at the cost of angular resolution."
Notice what every example shares: a number, a test date, a threshold, and a named action. None of them say "may not work as expected."
How each agency scores your SBIR technical risk section
The audit exists because omitting technical risk depresses a specific scored factor, not just "the whole application."
| Agency | Scored factor affected | Where reviewers look |
|---|---|---|
| NASA SBIR | Factor 1 (Technical Merit) | Work plan and risk register |
| NIH SBIR | Approach | Specific Aims pitfalls sentence, Research Strategy |
| NSF Pitch | Intellectual Merit | Technical Objectives section |
| ARPA-H | Technical Risk (explicit) | Proposed Work, Go/No-Go gates |
| ARPA-E | Approach & Key Risks (explicit) | Concept paper's Approach & Key Risks discussion (position varies by FOA) |
| AFWERX | Technical merit (statutory SBIR/STTR criterion) | Work plan or pitch deck, depending on solicitation track |
Two agencies name the risk section explicitly in their templates: ARPA-H and ARPA-E. If you're applying to either, there is no ambiguity about whether reviewers expect this. For NIH and NASA, the risk statement is folded into a section that also has to do other work, which is exactly why founders skip it. It isn't its own labeled box, so it's easy to forget.
Where the technical risk section physically goes
- NIH SBIR: each Aim in the Specific Aims page ends with a one-sentence "potential pitfalls and alternatives" statement. In the Research Strategy, each Aim gets its own Potential Pitfalls and Alternatives subsection, per NIH study-section convention.
- NASA SBIR: the Technical Volume's work plan includes a risk register, cross-referenced against the narrative. A risk that appears in the register but not the narrative reads as an oversight, not a feature.
- NSF Pitch: each technical objective in the Technical Objectives section carries its own risk-and-mitigation pair.
- ARPA-H: Go/No-Go gates in the Proposed Work section double as risk mitigation. Each gate should map to a named technical risk.
- ARPA-E: the concept paper has an explicitly titled Approach & Key Risks discussion. This is not optional or implicit; the discussion exists specifically for this content, though where it falls in the template varies by FOA.
- AFWERX: each task in the work plan (or each claim in the pitch deck, for Open Topic Phase I submissions) should carry its own risk and mitigation. Before you submit, check your own draft the way Cada checks its clients' drafts internally: have someone read it cold and ask whether they can find the risk statement without you pointing to it.
Pre-submission checklist
Run this against every Aim, Objective, or Task before you submit:
- At least one named technical risk (material, biology, algorithm, hardware, measurement, or first-time integration)
- The risk is stated as a specific mechanism, with a number where possible, not a category label
- The mitigation names a concrete action and a trigger threshold, not "we will monitor"
- An independent fallback exists, or you've decided consciously to accept the weaker single-mitigation version
- No risk is labeled "schedule," "personnel," "supply chain," or "contracting" and counted as technical
- Any risk that appears in a separate risk register also appears in the Aim's own narrative
- The risk sentence sits inside the section reviewers expect it in for your specific agency (see the table above)
If any line fails, the fix is usually one sentence, not a rewrite of the Aim.
Where the fee earns its keep
None of the taxonomy above is proprietary. Any founder can sort their risks into the right categories and write a mitigation with a threshold.
Where it gets harder is judgment specific to your proposal:
- deciding which risk is the one a reviewer in your specific field will find credible, versus one that reads as padding
- setting a trigger threshold a reviewer will accept as rigorous, not arbitrary
- knowing whether your fallback is genuinely independent or secretly depends on the same assumption as your mitigation
- placing the risk statement in the exact spot your target agency's reviewers expect it
Cada has worked on hundreds of proposals across 30+ agencies, and a disproportionate number of revision rounds trace back to exactly this section, because it's the one founders are most tempted to skip or soften.
If you want a second read, send us your SBIR technical risk section and we'll do a free 15-minute audit: which Aims are missing a technical risk, which mitigations are too vague, and where a fallback would strengthen your score. No pitch, no obligation.
Every example in this piece is illustrative. Confirm program specifics, page limits, and review criteria against your current solicitation.