Plan application security work in the same capacity conversation as features. Bring a short list of verified issues, bounded investigations, and prevention work, then ask the product and risk owners to make explicit tradeoffs against available engineering days. Reserve time to verify fixes, not merely merge them. Keep a separate urgent path for suspected active abuse or a materially exposed issue. If a decisive fact is missing, fund an evidence task and give any repair estimate as a conditional range. A cheap protective correction may be worth scheduling in parallel.
There is no universal percentage of sprint time that makes a team secure. The useful rule is that the calendar must reflect the chosen risk response. NIST's Cybersecurity Framework 2.0 supports assessing, prioritizing and communicating cybersecurity work in organizational context; it does not prescribe one engineering allocation. OWASP SAMM's Strategy and Metrics practice similarly calls for a software security plan aligned to organizational objectives. The manager's job is to make that plan deliverable rather than assume security work will happen “between features.”
Bring comparable work to planning
The AppSec lead should supply a one-page packet before the meeting. For each candidate item, it should state the affected product or customer action, the actor and prerequisites, whether the issue is verified or still being investigated, the evidence revision, the business consequence if left open, the proposed next step, the engineering estimate with uncertainty, and the owner who can answer questions. Technical severity is one input, not a substitute for those facts. FIRST's CVSS v4.0 specification distinguishes base severity from threat and environmental context; local priority also depends on business impact and the cost of delaying other work.
The engineering manager brings actual allocatable capacity: leave, support rotation, carryover and review load already deducted. Product brings feature deadlines and their reasons. The service owner brings deployment and control facts. An executive or delegated business risk owner should take responsibility when deferring a material risk to make room for a feature. That is a decision, not a technical finding, and it should be recorded separately from the finding's status.
Do not put all security work under “bugs.” There are three different shapes of work:
| Shape | Planning unit | What counts as done |
|---|---|---|
| Verified open issue | A scoped fix plus a separate validation step | The unsafe path is positively checked at a new revision; inconclusive remains open. |
| Plausible unresolved claim | A timeboxed question with required artifact and reviewer | The question is answered or a named blocker and date are recorded; investigation is not called a fix. |
| Prevention or design | A control decision tied to an upcoming change | A documented rule and evidence that the implementation follows it on the relevant path. |
The NIST Secure Software Development Framework, RV.2 calls for analyzing vulnerabilities and planning remediation or another risk response. It also treats identifying and responding to vulnerabilities as work in the development process. That is why a repair estimate that excludes verification is incomplete: it budgets the code change while leaving the decision about closure unfunded.
Work an illustrative two-week plan
Illustrative case, not a report of customer work: Meridian Booking has a small team with 24 allocatable developer-days in the next two-week sprint after support duty, meetings and leave. The product owner wants a booking-rule feature. A security review has independently supported an authorization gap on one staff export path at a pinned revision; it has not executed an exploit. A second alert about customer-data caching lacks deployment evidence. The manager writes the candidates in one table before promising a schedule.
| Candidate | Current evidence and consequence | Estimated effort | Decision |
|---|---|---|---|
| Booking-rule feature | Committed customer workflow; design includes a new privileged adjustment path | 16 days, including 1 day to review the new authorization rule | Include, with security acceptance criteria in the feature ticket. |
| Staff export authorization fix | Verified missing object ownership check on the traced path; possible access to another account's export | 4 days to change and review code | Include before widening staff access. |
| Cache alert investigation | Cache service and production route mapping are missing; customer-data effect is conditional | 2 days to obtain config and trace read path | Include as an evidence task; replan if confirmed. |
| Export fix reassessment | New revision must show the expected denial and preserve authorized exports | 1 day for reviewer and controlled validation | Include; do not close on merge alone. |
| Capacity buffer | New evidence or a failed deployment check may change the plan | 1 day | Hold visibly, not as a hidden second feature. |
| Optional reporting polish | Useful but less time-sensitive product improvement | 5 days | Defer; product owner records the effect of delay. |
The selected work totals 24 days. The numbers are invented to show the tradeoff, not to recommend a staffing ratio. The manager does not claim that the export issue is “more severe than the feature.” The decision is narrower: the impact and known path justify four days of repair and one day of verification now, while the optional polish moves. The feature's authorization review is inside its estimate so the team does not create the next backlog item while clearing the previous one.
Replan with work already spent
At the checkpoint, assume eight days have been spent: four on the feature, two on the cache investigation and two on the export repair. The cache evidence now supports a cross-account read; independent approval is supplied as an exercise premise. Its owner estimates one day to restrict the affected cache path and coordinate release, four days for the durable correction, and one day for reassessment: six additional days. The original one-day buffer covers only one of them.
The optional five-day polish was already excluded. “Pause optional polish” therefore frees zero days from the committed plan. The manager must cut actual committed work or change the delivery promise.
Product identifies a five-day advanced booking-rule variant that can be removed without undoing the four days already spent. The reduced feature still includes its one-day authorization review. The revised whole-sprint ledger is:
| Selected work | Revised total days | Already spent | Remaining |
|---|---|---|---|
| Reduced booking-rule feature | 11 | 4 | 7 |
| Export repair | 4 | 2 | 2 |
| Cache investigation, now complete | 2 | 2 | 0 |
| Export reassessment | 1 | 0 | 1 |
| Cache restriction, repair and reassessment | 6 | 0 | 6 |
| Unallocated buffer | 0 | 0 | 0 |
| Total | 24 | 8 | 16 |
The new cache work is funded by five days removed from a committed feature plus the original one-day buffer. No investigation time is refunded, and verification remains funded for both repairs. Engineering confirms that the chosen people can perform the remaining work in sequence; equal totals alone would not resolve a specialist bottleneck.
The alternative is to retain the full feature, producing 29 days of committed work. That requires five genuinely available, qualified days or a changed release sequence. Product chooses the 24-day plan and tells the feature stakeholder exactly which variant moves. Head of Engineering records that the buffer is exhausted; another failed check now requires another explicit tradeoff.
If the cache investigation instead finds a mandatory account partition on the exact read, the reviewer records the defeating evidence and the original 24-day plan remains valid. The two investigation days are still spent. The one-day buffer remains available; there is no six-day repair to schedule. An investigation buys a decision, so its value does not depend on producing a vulnerability.
Use a six-step planning rhythm
1. Set an intake cutoff and an urgent route. Ordinary scanner leads enter the next review cycle. A credible report of active exploitation or a potentially severe exposure goes to the response owner immediately. An urgent route is not a promise that the claim is already verified; it is a way to contain possible harm while checking evidence.
2. Freeze the planning snapshot. List candidate work with its revision, scope, evidence status and owner. Add new findings later through an explicit replan. Without a snapshot, the security queue can appear to change under the manager during every meeting.
3. Compare consequences in plain language. Ask what customer action or asset is at stake, how hard the harmful path appears to use, which controls are known to work, and what is still assumed. Keep severity, practical difficulty, impact and business priority separate. Do not turn an unverified scanner description into a confident business-loss estimate.
4. Allocate full work units. A fix unit includes code change, review, deployment coordination and positive reassessment. An investigation unit includes the artifact request and decision meeting. A design unit includes acceptance checks. Assign one directly responsible owner and one decision date to each.
5. Name deferrals. When the team cannot fit every verified issue, write which risk is deferred, why, until when, what interim control applies and who is authorized to accept the residual risk. Use an exception only when those facts can be reviewed. A blank “next sprint” label is not an expiry.
6. Reconcile at sprint end. Compare the selected work to what was done. Classify a fix as positively verified, still open or inconclusive. Report investigations that gained or failed to gain their missing fact. Carry the exact residual decisions into the next plan, rather than resetting the queue to the latest scan output.
This cadence can be lightweight. A manager can use an ordinary planning sheet if it preserves the evidence and decision links. The important property is that security and feature owners see the same constrained calendar. If security fixes routinely spill because feature deadlines always win, the next leadership discussion needs the explicit list of risks and tradeoffs, not another request for the team to “care more.”
Check specialist capacity after the totals fit
A plan can total 24 days and still be impossible if the same person owns both critical reviews. Before accepting the revised ledger, map each dependency to the people and release windows that can satisfy it. Meridian's cache correction may need the same data-service engineer as the export repair; equal developer-day totals do not show whether their work can run in parallel.
Resolve that conflict by sequencing the work, narrowing a feature, adding qualified help or changing the release commitment. Do not quietly remove reassessment from the estimate because it appears at the end of the plan. A correction awaiting a reviewer remains unfinished security work.
Record the first checkpoint at which the plan could fail: missing cache configuration, an incompatible shared helper or an unavailable release owner. This gives the manager an early opportunity to replan, before the team has spent the remaining capacity and discovers that the intended closure cannot happen.
Copy a short planning agreement
Planning period and allocatable engineering days:
Product commitments and the cost of moving each:
Verified security work: finding, effect, owner, fix estimate, validation estimate
Investigations: precise missing fact, evidence owner, timebox, decision date
New feature security decisions: expected rule and acceptance evidence
Urgent escalation trigger and response owner:
Selected work and total days:
Deferred risks, interim controls, business approver, next decision date:
End-of-period outcomes: verified fixed / still open / inconclusive
If no capacity remains after a required feature, do not put a material issue in an unowned backlog and call the plan balanced. Give the sponsor an actual choice: reduce feature scope, add qualified capacity, change the release sequence, mitigate the risk, or accept it under the organization's authority and time limits. Preserve what is unknown. A source-only review cannot confirm a production route by itself; a missing deployment fact may change the rollout effort or priority, so identify the platform owner and the assumption behind the estimate.
For the next planning meeting, select at most the consequential few items from the backlog workflow, add the validation days, and put them next to the feature estimates. If a verified risk must wait, complete the exception record before the meeting ends.