Security feature launch readiness evidence pack
so every product feature ships with a documented threat-model delta, scan record, exception decision, and named approver
AppSec, product security, and security engineering teams meet feature launches dozens of times a release cycle. Each launch needs a defensible answer to the same questions: what changed in the threat model, which baseline scans ran against the change, which findings still sit open at ship time, what exception decisions absorb residual risk, and who signed the launch gate. Run launch readiness as a per-feature workflow on the engagement record so the evidence pack assembles from live workspace data rather than from a slide deck a security lead writes once and never references again.
No credit card required. Free plan available forever.
Ship features with a defensible security evidence pack on the engagement record
AppSec, product security, and security engineering teams meet feature launches dozens of times a release cycle. Each launch needs a defensible answer to the same questions: what changed in the threat model, which baseline scans ran against the change, which findings still sit open at ship time, what exception decisions absorb residual risk, and who signed the launch gate. Run launch readiness as a per-feature workflow on the engagement record so the evidence pack assembles from live workspace data rather than from a slide deck a security lead writes once and never references again. The engagement is the boundary every launch decision lands on so the next audit, the next leadership read, and the next launch reviewer all reference the same record.
This is the per-feature gate that runs on top of the application baseline established at intake. For the once-per-application onboarding workflow that establishes the baseline, read the new application security onboarding workflow. For the steady-state SDLC handoff between security and engineering once the feature ships, read the SDLC vulnerability handoff workflow. For the platform-level paved-path posture engineering builds around, read the internal developer platform security guardrails workflow. For the standing disposition meeting that reviews aged exceptions and material decisions, read the security finding disposition meeting workflow.
Eight failure modes that quietly break launch readiness
Every launch readiness failure that produces aged findings, audit gaps, or post-launch surprises traces back to one of the same eight modes. Each one is invisible at launch time and visible at the next scan, the next audit, or the next leadership read.
Launch readiness is a hallway sign-off, not a documented gate
A product manager pings the security lead in chat the day before launch and asks "any blockers?" The security lead glances at recent scans, says no, and the feature ships. Six weeks later, an external scanner picks up a regression on the new surface, and the audit cycle that follows has no record of who looked, what they looked at, or what they decided. Launch readiness has to be a documented gate, not a hallway response.
No threat-model delta, so the change is invisible to security review
The application has a threat model from onboarding. The feature ships without recording what changed about it. When a downstream finding lands on the new authentication flow, the new data-handling path, or the new external endpoint, nobody can reconstruct whether the change was reviewed or whether the new trust boundary was assumed. The threat-model delta is the artefact that connects the launch decision to the architectural decisions it ratified.
Scans run against the wrong scope or the wrong branch
Code scanning runs against the main branch the night before launch and never sees the feature branch. Authenticated DAST runs against last week's staging snapshot rather than the staging build carrying the new endpoints. External scanning checks the existing domain but misses the new subdomain the feature exposes. Pre-launch scanning has to land against the actual change scope, not against the steady-state baseline that was already clean.
Findings hit the queue with no calibration for the launch context
A SAST finding on a public-facing path with regulated data ships at the same severity as the same finding on an internal experiment. The launch gate cannot tell the difference between findings that should block the release and findings that can carry forward. Calibration that bakes in the data classification, the exposure, and the reachability of the changed surface has to land at intake, not be re-argued every time a finding moves toward the gate.
Exceptions ship without expiry, without compensating control, and without an approver
A finding stays open because the engineering team commits to fixing it next sprint. There is no documented exception, no named compensating control, no recorded approver, and no expiry. Three quarters later, the finding is still open, the next launch reviewer has no record of why it shipped, and the audit finds an aged exception with no provenance. Launch exceptions belong in the structured eight-field exception register from day one.
No named approver, so accountability evaporates after the release
The launch ships. Nobody signed off in writing. When a customer questionnaire asks who approved the security posture of the release, the security team reconstructs the answer from chat history and calendar invites. When an audit asks for the launch decision record, there is nothing structured to point at. The named approver, the timestamp, and the rationale have to land on the activity log so accountability survives the calendar quarter.
The evidence pack is reconstructed at audit time, not assembled at launch time
Six months after launch, an auditor asks for the security artefacts that accompanied the release. The security lead spends two days reconstructing the threat-model thinking, hunting for scan output, screenshotting the exception register, and writing a retrospective narrative that paraphrases what they remember of the launch decision. An evidence pack assembled at launch time from the engagement record is the only way this work scales beyond a handful of releases per quarter.
Launch findings never transition into the steady-state backlog
The launch engagement closes when the feature ships. The findings that shipped open under exceptions, the findings that carried forward, and the post-launch verification scans all live as orphan artefacts disconnected from the application's ongoing backlog. By the time the steady-state cadence picks them up, the launch context is gone and the original calibration has to be reconstructed. The transition out of launch readiness is part of the workflow, not a separate manual step.
Six fields every launch evidence pack has to carry
A defensible launch evidence pack is six concrete fields on the engagement record, not a free-form launch document a security lead writes once under deadline pressure. Anything missing from the list below is a known gap in the launch trail rather than something an assessor will spot in time.
Launch metadata
The feature name, the parent application reference, the release identifier or change batch, the rollout shape (full release, gradual rollout, dark launch, feature flag, beta cohort), the target launch date, the named product owner on the engineering side, the named security owner on the workspace side, and the data classification or regulatory tags. The metadata anchors every downstream decision so the evidence pack ties back to the same release the audit asks about.
Threat-model delta
A structured record of what changed against the application baseline: new trust boundaries, new authentication surfaces, new data flows, new third-party dependencies, new permissions, new external endpoints, new privileged paths, and new logging coverage. The delta sits on the engagement as an attached document or as an organised set of intake findings so the next reviewer reads the change against the prior state.
Pre-launch scan output
The code scan against the feature branch (SAST plus dependency analysis), the authenticated DAST run against the staging build carrying the new endpoints, and the external scan against any new domain, subdomain, or public surface. Each scan record carries the scanner reference, the rule pack version, the scan timestamp, and the scan ID so the evidence trail is provenance-aware rather than asserting that scans happened.
Calibrated launch finding queue
Each finding carries the CVSS 3.1 vector, the workspace-calibrated severity, the data-classification adjustment, the exposure note, the reachability note, the named remediation owner, and the launch gate disposition (must close before launch, ship with exception, carry forward under SLA). The queue is the calibrated picture the launch decision reads against rather than a raw scanner dump.
Exception decisions and compensating controls
For findings that ship open, the structured exception entry: the linked finding, the calibrated severity, the named compensating control with explicit rule, segment, or query reference, the residual likelihood, the residual impact, the business rationale, the documented expiry date, and the review cadence. The exception is attached to the launch engagement so the audit reads it back to the release that approved it.
Residual risk note and named approver
A short narrative summarising the net launch risk in language the product owner and the named approver sign off against rather than as a pile of finding IDs. The named approver, the timestamp, the rationale, and the decision (approve, approve with exceptions, hold, reject) land on the activity log so the launch is a documented gating event rather than an asserted process.
Launch readiness checklist
Before any feature transitions from launch readiness to ship, the security owner, the product owner, and the engineering lead walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- A new feature, release train, change batch, or material product surface heading toward a launch decision triggers a launch readiness engagement on the workspace.
- The launch metadata (feature name, parent application, release identifier, rollout shape, target launch date, named owners, data classification) is recorded on the engagement before scanning starts.
- The threat-model delta against the application baseline is captured and attached as a document or as a structured set of intake findings on the engagement.
- Code scanning runs against the feature branch with SAST through Semgrep and dependency analysis on the connected repository.
- Authenticated DAST runs against the staging build carrying the new endpoints using credentials encrypted at rest in the workspace.
- External scanning runs against any new domain, subdomain, or public surface the feature exposes.
- Each launch finding receives a CVSS 3.1 vector, a workspace-calibrated severity adjusted for data classification and exposure, and a named remediation owner.
- The launch gate rule is documented on the engagement: which severities must close before launch, which can ship with an exception, which carry forward under SLA.
- Findings that match an active exception in the workspace exception register inherit the documented decision rather than re-opening parallel records.
- Findings that ship open under a fresh exception land in the eight-field finding override workflow with compensating control, expiry, and review cadence.
- The residual risk note summarises the net launch risk for the named approver in language the product owner can sign off against.
- The launch gate decision (approve, approve with exceptions, hold, reject) lands on the activity log with the named approver, the timestamp, and the rationale.
- AI report generation drafts the executive narrative for the product owner, the engineering lead, and the security approver from the engagement record.
- The evidence pack is exported (or kept on the engagement for live audit reads) so the launch decision is reproducible later.
- Once the launch ships, launch findings transition into the steady-state backlog under the parent application's standard SLA.
- The retesting workflow verifies post-launch that closed findings stayed closed in production rather than only in staging.
How launch readiness looks in SecPortal
Launch readiness is one workflow stitched into eight capability surfaces: the engagement record, the repository connection, the verified domain, the encrypted credential store, the scan executions, the findings record, the exception register, and the AI-generated launch readiness report. The work that has to happen at each stage is the same work the platform already supports for everyday operations; the launch readiness layer just makes the threat-model delta, the pre-launch scan output, the calibrated queue, and the named approval explicit on a single launch engagement.
Engagement as the launch record
The launch metadata, the threat-model delta, the pre-launch scans, the calibrated findings, the exception decisions, the residual risk note, and the named approval all sit on the same engagement record. Every launch readiness event for every feature uses the same record schema so the release-gate picture is comparable across features rather than ad hoc per ship.
Repository scanning on the change branch
The feature branch is scanned through the connected repository connection so code scanning runs SAST through Semgrep and dependency analysis on the actual change rather than on the steady-state main branch.
Authenticated DAST against the staging build
Pre-launch authenticated scanning exercises the new endpoints, the new privileged paths, and the new flows on the staging build using credentials encrypted at rest through encrypted credential storage, so the team stops circulating session cookies and bearer tokens through shared password managers at release time.
External scanning on the new surface
Any new domain or subdomain the feature exposes is verified through domain verification so external scanning can run against the new public surface alongside the existing perimeter, surfacing header, TLS, and exposure issues before launch.
Findings on one record
Pre-launch findings from code scanning, authenticated DAST, external scanning, and the threat-model delta land on a single findings record with CVSS 3.1 vectors, calibrated severities, evidence, and remediation guidance. The launch queue is one queue rather than four parallel ones the security lead has to reconcile by hand.
Exception register on the launch gate
Findings that ship open under documented exceptions land in the structured eight-field finding overrides register: linked finding, calibrated severity, compensating control with explicit reference, residual likelihood, residual impact, business rationale, expiry, and review cadence. The exception attaches to the launch engagement so the audit reads it back to the release that approved it.
AI-generated residual risk narrative
The launch engagement produces the residual risk note and the executive narrative through AI report generation. The product owner, the engineering lead, and the named security approver read the launch decision in product-and-business terms without the security lead authoring the narrative from scratch under release-day pressure.
Activity log as the named-approval trail
The launch gate decision (approve, approve with exceptions, hold, reject), the named approver, the timestamp, and the rationale all land on the activity log with user attribution. The CSV export is the audit evidence ISO 27001, SOC 2, PCI DSS, NIST SSDF, and NIST SP 800-53 assessors expect for documented per-change review.
Post-launch retest and continuous monitoring
Once the feature ships, the retesting workflow verifies that closed findings stayed closed in production rather than only in staging, and continuous monitoring picks up the new surface under the standard daily, weekly, biweekly, or monthly cadence so the feature stays under coverage between release events.
Severity calibration at the launch gate
Severity calibration sits at the centre of the launch gate. A SAST finding on a public path carrying regulated data is not the same as the same finding on an internal feature flag. A DAST finding on a new privileged path is not the same as the same finding on an existing read-only path. A dependency advisory on a transitively-imported package the feature does not reach at runtime is not the same as the same advisory on a directly-imported package handling the new authentication flow. Calibrating once at the launch gate (with the change scope, data classification, exposure, and reachability already on the engagement) means the launch decision is read against calibrated evidence rather than raw scanner severity. The calibration method aligns with the broader vulnerability prioritisation workflow so the launch-gate severities mean the same thing as the steady-state severities the team operates against later.
What auditors expect from per-change security review
Per-change security review evidence shows up in audit reads whenever an external assessor reviews how material changes reach production. The frameworks below all expect a documented gate plus enforcement evidence rather than a slide that names the cadence without proving it.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 8.25 (secure development lifecycle), 8.27 (secure system architecture and engineering principles), 8.28 (secure coding), 8.29 (security testing in development and acceptance), and 8.32 (change management) all expect documented per-change security review plus enforcement evidence. The launch readiness engagement record (threat-model delta, pre-launch scans, calibrated queue, exception decisions, named approval) is the artefact the audit reads against for material feature changes. |
| SOC 2 | Common Criteria CC8.1 (change management) expects documented authorisation, design, development, testing, and approval for changes to systems and software in scope. CC7.1 and CC7.2 expect monitoring and incident detection across the change. The launch readiness evidence pack maps directly: the engagement captures authorisation (named approver), design (threat-model delta), development testing (pre-launch scans), and approval (gate decision on the activity log). |
| PCI DSS | Requirements 6.2 (custom and bespoke software developed securely), 6.3 (security vulnerabilities identified and addressed), 6.4 (changes managed securely), and 11.3 (vulnerabilities identified and addressed periodically) all expect documented intake for changes to in-scope systems. Pairing the threat-model delta, the pre-launch scans, the calibrated severity decisions, and the named approval to the launch engagement satisfies the documentary trail the assessor expects for new and changed features. |
| NIST SSDF (SP 800-218) | PW.1 (design software to meet security requirements and mitigate security risks), PW.7 (review and analyse human-readable code), PW.8 (test executable code), PS.1 (protect all forms of code from unauthorised access and tampering), and PO.5 (implement and maintain secure environments for software development) all map to per-feature launch review. The launch engagement record captures the artefacts SSDF practice expectations read against rather than as a parallel artefact at audit time. |
| NIST SP 800-53 | Controls CM-3 (configuration change control), CM-4 (impact analyses), SA-8 (security and privacy engineering principles), SA-11 (developer testing and evaluation), and CA-7 (continuous monitoring) all expect documented change review plus enforcement evidence. The launch readiness engagement is the source of derivative evidence for these controls as a single record rather than as four parallel artefacts. |
| OWASP SAMM | The Verification business function (Architecture Assessment, Requirements-driven Testing, Security Testing) and the Implementation business function (Secure Build, Secure Deployment, Defect Management) both expect documented per-release verification. The launch engagement carries the architecture-delta record, the requirements-driven test evidence, the security test output, the build provenance, and the defect-management decisions on one record so the SAMM maturity read is a derivative artefact of the workflow. |
Where launch readiness fits across the security lifecycle
Launch readiness sits between application onboarding and steady-state operations. Every upstream workflow feeds it, and every downstream workflow inherits the launch record so the feature ships with a clean evidence pack rather than as a hallway negotiation.
Upstream and adjacent
Launch readiness depends on new application security onboarding for the application baseline the delta is measured against, on internal developer platform security guardrails for the paved-path posture engineering builds around, on asset criticality scoring for the data-classification context the launch-gate severity calibration reads against, and on the standing security finding disposition meeting for the cadenced review of aged launch exceptions.
Downstream and steady-state
Launch readiness feeds devsecops scanning for the steady-state cadence the feature transitions into, SDLC vulnerability handoff for the ongoing engineering-to-security loop, security finding fix verification for the post-launch retest discipline, and audit fieldwork evidence request fulfillment when the assessor asks for the documented per-change security review record.
What good launch readiness feels like
Launch is a documented gate, not a hallway approval
The launch decision (approve, approve with exceptions, hold, reject) is recorded on the activity log with the named approver, the timestamp, and the rationale. The audit reads a documented gating event rather than reconstructing one from chat history six months later.
The threat-model delta is current, not stale
Every material change updates the threat model on the engagement. The next reviewer reads the change against the prior state. The application threat model stays alive rather than freezing at onboarding and aging into irrelevance.
Exceptions have a name, a control, and an expiry
Findings that ship open carry a structured exception with a named compensating control, an explicit expiry, and a review cadence. The exception register catches aged decisions on review rather than letting them drift forever.
The evidence pack assembles from live data
The engagement record is the evidence pack. AI report generation drafts the narrative. Document management retains supporting artefacts. The audit cycle reads live workspace data rather than a parallel artefact assembled at audit time.
Buyer and operator pairing
Who runs launch readiness day to day
Launch readiness is the workflow AppSec teams run as the front gate on every material product change, the workflow product security teams run when a product line ships a new capability or surface, the workflow security engineering teams run as the cross-cutting record between application owners and the security programme, and the workflow application security program leads read as a headline cadence of programme discipline. CISOs and security leaders read the launch cadence, the disposition mix, the exception register churn, and the post-launch verification rate as a leading indicator of how disciplined the front gate is. GRC and compliance teams read the launch engagement directly when ISO 27001, SOC 2, PCI DSS, NIST SSDF, and NIST SP 800-53 audits ask for documented per-change security review evidence.
Honest scope: what SecPortal does and does not do at the launch gate
SecPortal runs the security-side launch readiness workflow on the workspace. It is not the engineering change-management tool, not the feature-flag platform, not the release orchestration system, and not the build pipeline. The named scope below stays honest about the surface area.
What SecPortal handles
The launch engagement record, the threat-model delta attached as a document or structured finding bundle, the pre-launch code, authenticated DAST, and external scan runs against the change scope, the calibrated finding queue, the eight-field exception register entries, the AI-drafted residual risk narrative, the named-approver decision on the activity log, the post-launch retest record, and the framework-citation evidence-pack assembly.
What SecPortal does not handle
SecPortal does not push tickets into Jira, Linear, ServiceNow, Asana, Shortcut, Slack, Teams, or PagerDuty. It does not host the feature flag, does not gate the release pipeline, does not drive the CI/CD deploy, does not control rollout percentage, and does not orchestrate dark launches. It is not a change-advisory-board tool, not a governance-risk-compliance platform, and not an identity provider. It does not provide enterprise SSO, SCIM, or SAML, and does not ship automated approval routing across external systems. The security-side launch evidence pack lives in SecPortal; the engineering-side change record lives in the engineering system; cross-references travel both ways through finding and engagement metadata.
How it works in SecPortal
A streamlined workflow from start to finish.
Open a launch readiness engagement against the feature, release, or change scope
When a feature, release train, change batch, or material product surface heads toward a launch decision, a launch readiness engagement opens on the workspace. The engagement carries the feature name, the parent application reference, the named product owner on the engineering side, the named security owner on the workspace side, the target launch date, the rollout shape (full release, gradual rollout, dark launch, feature flag, beta cohort), and the data-classification or regulatory tags that apply. The engagement is the boundary every launch decision lands on so the evidence pack is reproducible later rather than reconstructed from chat threads under audit pressure.
Capture the threat-model delta against the previously approved baseline
A new feature is rarely a fresh threat model from scratch; it is a delta against the application baseline established at onboarding. Record what changed: new trust boundaries, new authentication surfaces, new data flows, new third-party dependencies, new permissions, new external endpoints, new privileged paths, and new logging coverage. The delta sits on the engagement as a structured set of intake findings or as an attached document so the next launch reviewer reads the change against the prior state rather than rebuilding context. The threat-model delta is the artefact the audit reads when ISO 27001 A.8.27, SOC 2 CC8.1, and NIST SSDF PW.1 ask whether security review accompanied the change.
Run targeted baseline scans against the feature surface before the launch gate
Pre-launch scanning runs against the change scope rather than the whole estate. Code scanning runs SAST through Semgrep and dependency analysis on the connected repository against the branch carrying the change. Authenticated DAST runs against the staging environment with credentials encrypted at rest in the workspace, exercising the new endpoints, the new flows, and the new privileged paths the threat-model delta identified. External scanning runs against any new domain, subdomain, or public surface the feature exposes. The targeted scans produce a launch-specific finding queue separate from the steady-state backlog so the launch gate reads against fresh evidence rather than aged context.
Triage launch findings against the launch gate severity rules
Each launch finding receives a CVSS 3.1 vector, a workspace-calibrated severity adjusted for the data classification and exposure of the changed surface, and a named remediation owner on the engineering side. The launch gate rule defines which severities must close before launch, which can ship inside a documented exception with a compensating control, and which carry forward into the steady-state backlog under standard SLA. The rules sit on the engagement so the launch decision is reproducible rather than negotiated under release-day pressure. Findings that match an active exception in the workspace exception register inherit the documented decision automatically rather than re-opening parallel records every release.
Record exception decisions, compensating controls, and the residual risk note for findings that ship open
Findings that cannot close before the launch and that the programme accepts to ship open land in the exception register through the eight-field finding override workflow: the linked finding, the calibrated severity, the named compensating control (with explicit rule reference, segment reference, or query reference), the residual likelihood, the residual impact, the business rationale, the explicit expiry date, and the documented review cadence. The exception is attached to the launch engagement so the audit reads it back to the release that produced it. The residual risk note summarises the net launch risk in language the product owner and the named approver can sign off against rather than as a pile of finding IDs.
Assemble the launch evidence pack from live workspace data
The evidence pack assembles from the engagement record automatically rather than from a parallel artefact: the launch metadata, the threat-model delta, the code scan output with rule references, the authenticated DAST output with module references, the external scan output with module references, the calibrated finding queue, the closure decisions, the exception register entries with expiry dates, the residual risk note, the named owners on both sides, and the document attachments. AI report generation drafts the executive narrative for the product owner, the engineering lead, and the security approver so the pack reads as a single defensible artefact rather than as a folder of screenshots.
Capture the named approval and the launch decision on the activity log
The launch gate decision (approve to ship, approve with documented exceptions, hold for remediation, reject for material residual risk) lands on the activity log with the named approver, the timestamp, and the rationale. The activity log carries every state change against the launch engagement from open through to the gate decision with user attribution, so the audit reads the launch as a documented gating event rather than as an asserted process. The CSV export preserves the chronology so the evidence pack survives a reorganisation, a tool change, or a multi-year audit lookback.
Transition the launch findings into the steady-state backlog with the evidence pack retained
Once the launch ships, the engagement transitions out of the launch readiness phase. Findings carried forward inherit the standard SLA against the parent application. Exceptions inherit their documented expiry and the next review cadence. The retesting workflow verifies post-launch that closed findings stayed closed in production rather than only in staging. The launch evidence pack remains attached to the engagement so the next launch reviewer, the next audit, and the next leadership read all reference the same record the launch was approved against. Continuous monitoring picks up the new surface under the standard cadence so the feature stays under coverage rather than dropping into a gap until the next release event.
Features that power this workflow
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
Find vulnerabilities before they ship
Test web apps behind the login
Vulnerability scanning tools that map your attack surface
Repository connections for SAST and SCA
Verify ownership before any scan runs
Encrypted credential storage for authenticated scans
Finding overrides that survive every scan cycle
Verify fixes and track reopens on the same finding record
Monitor continuously catch regressions early
Every action recorded across the workspace
AI-powered reports in seconds, not days
Document management for every security engagement
Compliance tracking without a full GRC platform
Collaborate across your entire team
Notifications and alerts for the people who carry the work
Ship features with a defensible security evidence pack, not a hallway sign-off
Threat-model delta, targeted baseline scans, calibrated finding queue, exception register, residual risk note, and named approver on one engagement record from change start to post-launch verification. Free plan available.
No credit card required. Free plan available forever.