Security Findings Management and Remediation Tracking Questions

Direct answer

Make the ticket the only place an action item is allowed to live. Every item from a review becomes a ticket in the tracker the owning team already uses, before the review meeting ends, with four mandatory fields (in the team's ticket tracker, such as Jira, a widely used tool for tracking work items): a named owner, a due date derived from severity, a written acceptance check, and a link back to the review. Then run a closed loop: automatic reminders, escalation when overdue, verification by someone other than the fixer, and a weekly reconciliation that catches items that never became tickets. You know it works when three leakage numbers stay near zero: items with no ticket, tickets overdue with no update, and tickets closed without evidence.

The process

1. Capture at the source. A review ends with a structured action list (a form or template), not free text in meeting notes. Rule: "no ticket, no action item". Tickets are created in the meeting or imported from the report the same day.
2. Ownership. The owner is a team resolved from a service catalog (a registry mapping each service to the team that runs it), plus a named individual assignee. Anything that cannot be resolved goes to a triage queue (a holding list where someone decides who owns the item) with a two-business-day limit, so "unowned" is a visible state with a clock, not a hiding place.
3. Deadline. The due date comes from a severity policy (for example critical 7 days, high 30, medium 90; these numbers are an illustrative policy, set your own). Extending a date needs a recorded reason and an approver.
4. Verification. The acceptance check is written when the ticket is created (see the worked example). States: Open, In progress, Fixed pending verification, Verified closed, Risk accepted (a senior owner has signed a written decision to live with the item unfixed until an expiry date). Only the verifier, not the assignee, can move a ticket to Verified closed.
5. Chasing. The tracker's automation rules send reminders at roughly half and 80% of the time budget, escalate an overdue ticket to the owner's manager and then to their director, and post a weekly digest of overdue items to team leads.

Tooling

• The team's existing tracker (Jira or equivalent) holds the tickets, with a label carrying the review ID.
• A small automation (tracker rules or a script on a schedule) creates tickets, sends reminders and escalations.
• A weekly reconciliation job compares the review's list of item IDs against tickets carrying that review's label and flags any item without a ticket. This is the piece that catches items that vanished before ever being tracked, which no dashboard of existing tickets can show.
• A dashboard of overdue, unowned and unverified items per team, reviewed in a standing meeting.

How you know it works

Also plant a canary: a harmless dummy action item in a review, and check it reaches a ticket, gets an owner and is chased. Audit a random sample of closed tickets each quarter against their evidence.

Worked example

A design review of a payments service ends with 7 action items, numbered R-41-1 to R-41-7. Six tickets carry the label review-R-41. The Monday reconciliation reports 6 / 7 = 86% coverage and names R-41-5 ("restrict the admin endpoint to the VPN (virtual private network)") as missing. A ticket is created that day. Its acceptance check (a written test for what "done" means) reads: "From outside the VPN, a request to the admin endpoint returns 403; the network rule change is linked; the security engineer reruns the request and attaches the result."

Tracing the chase on a ticket with a 30-day window created Monday 1 June: the half-way reminder goes out on 16 June (day 15), the 80% reminder on 25 June (day 24), and if it is still open at the 1 July deadline the manager is alerted, with the director notified a week later on 8 July. The ticket also shows, in one line each, its owner (the platform team resolved from the service catalog), that it sat in triage for one day before an owner was found, and that if it were formally risk accepted it would show that status with an expiry date such as 30 September.

If the tickets are created by automation

Some teams have a small program create the tickets when a review finishes. The review system publishes an event (a message saying "review R-41 completed") onto a queue (a waiting line of messages), and a consumer (the program reading that line) creates the tickets. Two ideas matter. Idempotent means running the same step twice has the same effect as once: the consumer first looks for an existing ticket with the item's ID and only creates one if none exists, so a retry or two consumers reading the same message cannot create duplicates. A poison message is one that fails every time it is processed; after a few retries it is moved to a separate dead-letter list and an alert is raised, so it cannot silently produce no ticket. The weekly reconciliation job is the safety net for both.

Trade-offs and pitfalls

• Ticket sprawl. Not every remark deserves a ticket, but every commitment does. If an item is a decision rather than a fix, it still gets a ticket whose done condition is "decision recorded".
• Auto-closing stale tickets to tidy the dashboard is how items vanish again. Escalate instead.
• Reminder fatigue. Escalate on a ladder rather than repeating the same nag, or people mute it.
• Gaming. Closing without a fix is prevented by the separate verifier and the evidence rule, not by exhortation.
• What would change the design: a five-person company can run this as a shared board reviewed weekly. The automation earns its keep when items arrive from many reviews, across many teams.

Direct answer

A stopgap that is not tracked becomes permanent. So the moment service is restored I turn it into a recorded, owned, time-boxed risk: written down in the incident timeline, converted to a ticket with a named owner and a due date, communicated to the people who own the risk, and closed only when the stopgap is removed and someone independent confirms it.

Worked scenario (illustrative)

During an outage, to let a failover database replica connect, an engineer changed a firewall rule (the network filter that decides who may connect) so the database port (5432, the door clients use to talk to it) accepted connections from every address on the internet (written 0.0.0.0/0) instead of only the replica's own address (10.0.4.17). Service returned in 10 minutes. The gap: the database is now reachable from outside, by anyone who can guess or find it, instead of by one server.

Step by step, in order

1. Document during the incident. In the incident timeline: exact change, who made it, time, and the gap it created. A one-line note beats memory later.
2. Create a temporary-mitigation record the same day. Fields: what changed and where, why, what risk it adds (who could reach what), compensating controls now in place (a compensating control is a temporary safeguard that reduces the risk while the real fix is pending, such as extra logging or an alert on connections from unexpected addresses), owner, expiry date, and the permanent-fix ticket link. Filled in for this scenario:

Record:        TM-2026-041
Change:        Firewall rule db-failover-allow, port 5432, source 0.0.0.0/0 (was 10.0.4.17/32)
Why:           Failover replica could not connect during the 2026-09-28 outage
Risk added:    Anyone on the internet can attempt to log in to the production database
Compensating:  Password-only logins disabled for non-replica users; alert on any 5432
               connection from outside 10.0.0.0/8; connection log reviewed daily
Owner:         Payments platform team lead
Expires:       2026-10-05
Permanent fix: SEC-2210 (restrict source to 10.0.4.17/32), due 2026-10-05

3. Turn it into tracked work. One ticket for the permanent fix (restrict to the specific hosts), owned by the service team, with a due date (for example 5 business days, since this is a live exposure). Also add it as an action item in the postmortem (the blameless review after an incident: it asks what failed in the system, not who to blame).
4. Communicate the risk. A short message to the service owner, the security team and the on-call manager: what is exposed, what compensates, when it ends, what triggers escalation. Plain wording, no blame. For example: "Since 14:10 today the production database port accepts connections from any internet address, a side effect of restoring failover. We have restricted logins and are alerting on outside connections. Fix is ticketed (SEC-2210), due Oct 5. If the alert fires, security will block the port immediately and we will take the failover replica offline until it is fixed."
5. Make the expiry enforceable. Tag the change with an expiry date, and run an alert that fires when an expired tag is still present. A calendar reminder alone is not enough, because it depends on someone remembering. Concretely: put a label expires=2026-10-05 on the firewall rule, and run a daily job that lists every rule whose expires date is earlier than today and pages the owner. On 2026-10-06 the broad rule shows up in that list if it still exists, without anyone having to recall it.
6. Replace and verify. Apply the proper rule, remove the broad one, test the failover still works, and have someone other than the author confirm from outside that the port is no longer reachable. Attach the evidence and close both the record and the ticket.

What would change my call

If the permanent fix needs weeks (for example a network redesign), I stop calling it temporary: it becomes a formal, time-limited risk acceptance (a written, signed decision by the person who owns the risk that the organisation will live with it for a stated period), with stronger compensating controls and a renewal date.

Pitfalls

• Closing the incident and the ticket together, so nothing carries the exposure forward.
• Blame-heavy wording that discourages people from disclosing stopgaps next time.
• "Fixed" declared without confirming the old rule is gone.

Direct answer

A regulated environment is one where law or contract (for example payment-card or healthcare rules) requires demonstrable security controls, so audits are formal. Treat it as a controlled experiment auditors can repeat: fix the metric definitions before quarter one, collect evidence as work happens, and let auditors sample a stratified population each quarter. "Effective" must mean more than "tickets closed": findings are fixed on time, the fix holds (verified by rescan, low reopen rate), and exceptions are deliberate and time-limited. Three consecutive quarters matters because auditors are looking for a consistent operating pattern, not one good week (an operating pattern is the same behaviour repeating over time). The table in section 3 uses "due in the quarter" as its denominator.

1. Metrics (define numerator, denominator and window; freeze the definitions)

Any change to a definition mid-way is documented with the date and the restated prior quarters. Auditors forgive an imperfect metric; they do not forgive a moving one.

Worked numbers for the other four metrics (illustrative, Q2):

• P90 time to remediate: P90 means 90% of findings were fixed in this many days or fewer. For 10 critical findings fixed in 3, 4, 5, 5, 6, 7, 8, 9, 12 and 30 days, sort them and take the 9th of 10 (0.9 x 10 = 9): P90 = 12 days. The single 30-day outlier does not move it, which is why the count is reported beside it.
• Reopen rate: 3 of the 60 findings closed in Q2 were reopened, so 3 / 60 = 5%.
• Aged backlog: 12 open findings are past due, 7 by 1-30 days, 4 by 31-90, 1 by more than 90.
• Exception health: 8 active risk acceptances, 1 expired without renewal, so 1 of 8 needs action now.

2. Sampling

• Population = all findings closed in the quarter, exported from the system of record (the one database treated as the official source) with a timestamp and hash before sampling. This is a different set from the SLA table's "due in the quarter" below: the 60 closed in Q2 include findings that were due earlier or later, and some findings due in Q2 were still open, which is why closed (60) can exceed due (50).
• Stratify (split the population into groups by severity) so rare, important items are not lost. Illustrative Q2 population of 60 closed findings: 6 critical, 18 high, 36 medium. Sample all 6 critical, 6 of 18 high, 6 of 36 medium = 18 items (30% of 60). The 6 per group is an example rule, not a standard: take every item in the rarest, riskiest group, and a fixed number from each other group, with the size agreed with the auditor in advance (that gives 100% of critical, 33% of high, about 17% of medium).
• Select randomly with a recorded seed (the starting number that makes a random draw repeatable) and script so the auditor can reproduce the draw. Agree the method and sample sizes with the auditor up front; do not pick your own "representative" items.
• For each sampled item, walk the chain: finding, ticket, fix change record, verification rescan, approvals.

3. Evidence and worked trend (illustrative)

The trend (75%, 80%, 85%) shows the process improving, and each quarter's package includes: the frozen metric definitions, the raw export and hash, the sample list with the seed, per-item evidence, the aged-backlog list with owners and plans, and the exception register. If a quarter dips, present the cause and corrective action; a documented dip handled well beats a suspiciously smooth line.

4. Retention

• Keep evidence at least as long as the strictest applicable requirement (the regulation, the framework and the contract), and long enough to cover the full three-quarter observation period plus the auditor's look-back (how far into the past they may ask to see evidence). Confirm the exact period with compliance or legal rather than assuming a number.
• Store immutably, with access logs, and keep the sampling scripts and metric queries with the data; a number without its query is not evidence.
• Delete personal data and secrets from screenshots before retention, or restrict access.

Trade-offs

• Continuous automatic collection is more work upfront but avoids a scramble of reconstructed evidence at quarter end.
• Tighter SLAs look better to auditors only if you can meet them; set them from your realistic P90, then improve.
• If a finding cannot be fixed, a documented, approved, expiring risk acceptance with a compensating control (an alternative safeguard reducing the risk) is a stronger audit story than a quietly aging ticket.

Direct answer

The one-pager (for the CISO, the chief information security officer, and the board) answers four questions in the order a board member asks them: are we safer or less safe than last quarter, what are the few risks that matter, what is being done, and what do you need from us? Every section either supports a decision or gives a trend they can hold us to; anything else goes to an appendix.

Outline (top to bottom)

1. Headline verdict (2 sentences). "Overall exposure fell/rose, driven by X." Why: a busy reader gets the answer even if they stop after the first line.
2. Trend scorecard (5 numbers, each with last quarter beside it). Suggested (illustrative numbers this quarter, with last quarter in brackets): open critical and high findings, 42 (51); remediation SLA compliance (service-level agreement: the promised fix-by time per severity); average age of open highs, 40 days (52); retest pass rate, 85% (80%); testing coverage, 83% (75%). Retest pass rate is the share of "fixed" items that pass verification; testing coverage is the share of internet-facing apps (reachable by anyone on the internet, so the most exposed) tested this quarter. Why: trends show direction, and boards compare quarter to quarter.
3. Top three risks in business language. Each: what could happen, to which business process, how likely, what is being done. Why: the board funds and prioritises business risk, not scanner counts.
4. Exceptions and accepted risks (an accepted risk is a formal, signed decision to leave a known finding unfixed for a stated period, with a named owner and an expiry date). How many, who signed, when each expires. Why: shows that "we chose to live with it" is deliberate, not neglect.
5. What changed and what testing found (one or two lines each). Why: connects the numbers to events (new product, new tool, new test scope).
6. Coverage limits. What was not tested. Why: honesty about blind spots protects credibility and prevents false comfort.
7. Decisions and asks (max 3, each with an owner and date). Why: a report with no ask is information; one with an ask gets action.

Worked example of one scorecard line

SLA compliance for high findings = highs closed within SLA divided by highs that came due in the quarter. If 24 highs came due and 18 were closed on time, that is 18 / 24 = 75%. Last quarter 15 of 20 (also 75%), so the trend line is flat, which is more useful to the board than a lone "75%".

The other scorecard lines, with numbers

• Remediation SLA compliance: the scorecard line is 75% (last quarter 75%), from the worked example above, so all five scorecard lines carry a number with last quarter beside it.
• Average age of open highs: add up the ages and divide by the count. Take a shrunken three-item list to show the arithmetic (the real scorecard covers all open highs, not three): open highs aged 10, 30 and 80 days average (10 + 30 + 80) / 3 = 40 days. Show the oldest (80) beside it, because an average hides it.
• Retest pass rate: 20 items were marked fixed and 17 passed the independent retest, so 17 / 20 = 85%. Last quarter 16 / 20 = 80%.
• Testing coverage: 30 of 36 internet-facing apps were tested, so 30 / 36 = about 83%. Last quarter 27 / 36 = 75%. Six apps were not tested, which goes in the coverage limits section.

Headline and top risk, filled in (illustrative)

• Headline verdict: "Exposure fell this quarter: open critical and high findings dropped from 51 to 42 and fixes are holding (85% passed retest). Six internet-facing apps were not tested, so the picture is incomplete."
• Top risk 1: "Anyone on the internet could read other customers' order history through the order-lookup page (a weakness found in testing). Likelihood: high, because the page is public. Business impact: customer notification duties and loss of trust. Being done: fix scheduled this sprint, a temporary filter in place, security retests before closure."

Pitfalls

• Counting only volume: total findings rising can mean better testing, not worse security. Pair volume with age and severity.
• Gaming: reopening as a "new" finding resets its age. Compute age from first discovery.
• More than one page of numbers: the board reads the first page only.

Direct answer

The dashboard answers one question for each audience: is our backlog getting healthier, and where is it not? It shows open volume by severity, how old items are against their deadlines, how fast they get fixed, whether closures were verified, and which teams and services hold the overdue items. Data comes from the ticket tracker (the source of truth), the scanners (for what was found), and the service catalog (a list that records which team owns each service), loaded daily into a warehouse table (a database table built for reporting, so heavy dashboard queries do not slow the live ticket tool). Trends use daily snapshots; the overdue-critical list refreshes hourly.

What it shows

Data sources and refresh

• Tracker API for status, dates, owner and evidence flags. Ingest via scheduled export or webhook events (the tracker sends an automatic message each time a ticket changes).
• Scanner feeds (through the central ingestion pipeline) for discovery date and coverage.
• Service catalog for the owner and criticality of each service.
• Refresh: a nightly snapshot table (a copy of every finding's status saved once per day, so one row per finding per day) makes trends and historical numbers reproducible. An hourly refresh of only critical overdue items feeds the on-call view. Executives see a weekly rollup (the daily numbers summed or averaged into one weekly figure).

Worked example

Open high-severity findings, with a 30-day deadline:

In the table, the 28% is 7 overdue of 25 open (7 / 25 = 0.28), so SLA compliance is the other 72%.

The table points straight at Checkout: 4 of its 8 items are overdue, so the first conversation is with that team, not a company-wide reminder.

The other panels, with numbers for one week

• Opened versus closed: 14 findings opened and 9 closed, so the backlog grew by 5. Keeping up would need closed to be at least opened.
• Verification rate: of those 9 closed items, 7 carry retest evidence, so 7 / 9 = about 78%.
• MTTR: the same 9 closed items were fixed after 10, 15, 20, 20, 25, 25, 30, 35 and 45 days from discovery. The total is 225 days, and 225 / 9 = 25 days. The single 45-day item is why the oldest-item figure sits beside the average.

Design choices and pitfalls

• Every ratio shows its numerator and denominator, or people quote percentages that hide a tiny base.
• Show the oldest open item and the overdue count, not only averages, since averages hide the worst case.
• Do not rank teams on raw counts: a team owning a large estate always looks worse. Normalise or show both.
• A dashboard nobody reviews is decoration. Attach it to a standing weekly meeting with named owners.
• Stale data is worse than none; show the "last updated" time on the page.