After Launch: Maintenance, Updates and Incident Response for Live Web Products

Launch day can feel like a finish line. For the people who keep a web product running, it is better understood as a starting point. Once real users depend on a product, the focus moves from building features to keeping the product healthy: maintaining it, updating it, watching it and being ready to respond when something goes wrong.

In this article we look at what that work involves, drawing on breach data from Verizon's 2025 Data Breach Investigations Report and on the incident response guidance NIST revised in 2025. Where we describe our own approach, we say so; where we rely on the sources, we cite them.

Why the threat picture matters for live products

The 2025 Verizon Data Breach Investigations Report analysed more than 22,000 security incidents, including 12,195 confirmed breaches ⁶. Two findings stand out for teams running web products. First, credential abuse (22%) and exploitation of vulnerabilities (20%) were the leading initial attack vectors ⁶. Second, vulnerability exploitation as an entry point rose by 34%, with a notable focus on zero-day exploits aimed at perimeter devices and VPNs ⁶.

For organisations in Europe, the regional figures are sharper. System intrusion breaches in EMEA reached 53%, nearly double the previous year's 27% ⁵. Globally, the share of breaches involving third parties doubled to 30%, which the report links to risk in supply chains and partner ecosystems ⁶.

Smaller companies are hit disproportionately. The report highlighted the outsized impact of ransomware on small and medium-sized businesses ⁶, and an IDC analyst quoted in Verizon's release said that ransomware was present in 88% of breaches at organisations lacking proper IT and security maturity, which are often SMB-sized ⁶. The same release put the median ransom payment in the previous year at US$115,000 ⁶.

None of this means a live product is doomed. It does mean that the work after launch is more than optional housekeeping.

Updates and patching: the unglamorous core

When Verizon's cybersecurity lead summarised the report, he named timely patching of vulnerabilities alongside strong password policies and security awareness training as part of a multi-layered defence ⁶. Since vulnerability exploitation is one of the two most common ways in ⁶, this is where a large part of our maintenance effort goes.

In practice, we think about updates in three layers:

• Application dependencies. Frameworks, libraries and packages the product pulls in. We treat each of them as part of the product's supply chain, which feels relevant given the reported rise in third-party involvement in breaches ⁶.
• Runtime and infrastructure. Operating systems, web servers, databases, container images and the hosting platform itself.
• Edge and access components. VPNs, gateways and other perimeter systems, which the 2025 report identified as a focus of zero-day exploitation ⁵.

Our aim is not to update everything the moment a new version appears. It is to know what is running, track what has changed, and have a predictable process for testing and shipping fixes. Patching also comes back during recovery: practitioner guidance lists patching or mitigating the exploited vulnerability as one of the checks to complete before a system returns to production ⁴.

Monitoring: deciding what to watch and why

Updates reduce exposure; monitoring helps a team notice when something gets through anyway. NIST's revised guidance reframes detection around continuous monitoring and encourages organisations to ask what they monitor and why, instead of only listing possible warning signs ². It recommends watching a broad range of sources, including assets, networks, personnel activity, technology usage, service providers and the physical environment ².

A few practical points stand out for web products:

• Log retention. According to one practitioner guide, many cloud services keep logs for only 30 or 90 days by default, which may not be enough to investigate an intrusion where the attacker stayed unnoticed for months ⁴.
• Escalation criteria. The same guide recommends writing down escalation criteria before an incident occurs. Without them, it warns, alerts can be mishandled in both directions: trivial events get escalated while real intrusions are overlooked ⁴. NIST's revised guidance similarly describes declaring incidents based on defined criteria that weigh risk against false positives ².
• Tracking. The guide notes that even a well-organised ticketing queue can work as an incident tracking system, so that no event gets lost ⁴.

One caveat: some practices in the revised guidance, such as SIEM and SOAR systems and automated alerting, are fairly advanced, and not every organisation has the budget or capacity for them yet ². Tandem's commentary suggests recognising the current state, making steady progress and using the guidance to argue for additional resources ².

Incident response as continuous work, not an emergency switch

On April 3, 2025, NIST finalised Special Publication 800-61 Revision 3, which describes how to build incident response into cybersecurity risk management in line with the Cybersecurity Framework (CSF) 2.0 ¹. It supersedes Revision 2, the Computer Security Incident Handling Guide ⁷. NIST says the guidance is meant to help organisations reduce the number and impact of incidents and make detection, response and recovery more efficient and effective ¹.

The biggest change is structural. Revision 3 organises incident response around the six CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond and Recover ⁴. NIST explains that Govern, Identify and Protect are preparation activities that sit outside incident response itself as broader risk management work that supports it, while Detect, Respond and Recover make up the response ⁸. Lessons learned from all activities feed into continuous improvement, which in turn informs every function ⁸.

NIST also notes that the details of how to carry out incident response change too often and differ too much across technologies and organisations to be kept in one static document ⁸. As a result, Revision 3 reads more like a best practices guide for management than a step-by-step playbook for responders ². One practitioner guide takes the view that most small and mid-sized organisations can keep running their existing four-phase playbooks while mapping the terminology to CSF 2.0 for governance and documentation ⁴.

The Sefism guide to Revision 3 interprets the change as treating incident readiness as something that runs through risk management all the time, rather than a process that only starts when an incident does ³. In its reading, how well a team responds rests largely on groundwork laid well in advance, such as knowing its assets, having protections in place and being able to spot trouble ³. We find that framing useful for live products, where much of that groundwork overlaps with ordinary maintenance.

Preparing before anything breaks

Bellator Cyber's practitioner guide calls preparation the most consequential phase of incident response ⁴. It highlights several steps that translate well to product teams:

• Named owners. Every function in the response plan, from authorising containment to deciding on external notification, is assigned to a named person with a documented backup instead of a generic team label, and the list is kept current ⁴.
• An inventory with priorities. All assets are listed and given criticality ratings ⁴.
• An out-of-band channel. Responders have a way to coordinate even if primary systems are compromised; the guide points out that ransomware operators often encrypt email and collaboration platforms to slow the response ⁴.
• Practice. The guide suggests tabletop exercises at least twice a year with varied, realistic scenarios to stress-test playbooks ⁴.

There is a business dimension as well. Bellator Cyber cites IBM's 2024 Cost of a Data Breach Report as finding that organisations with a tested incident response plan and a dedicated response team saved more than $1.4 million per breach on average compared with organisations that had neither ⁴. We are relaying that figure secondhand, as reported in the guide.

When an incident happens

In the practitioner guide's account, containment, eradication and recovery overlap in practice, and rushing one of them can undo the others ⁴. Containment stops the damage, eradication removes everything the attacker left behind, and recovery restores normal operation ⁴. The guide also notes that attackers often plant more than one persistence mechanism precisely so they can survive a partial cleanup ⁴.

Before a system goes back into service, the guide recommends confirming that malicious artifacts have been removed or the system rebuilt from a known-good image, that the exploited vulnerability has been patched or mitigated, and that monitoring is in place to catch any attempt to get back in ⁴. It describes a phased return to production, starting with the least sensitive systems, so that confidence can grow step by step ⁴.

Communication is part of the response, too. NIST's revised guidance treats it as a coordination effort that can include notifying customers and regulators when needed, handling media inquiries and complying with changing incident reporting rules ². Which obligations apply to a particular product is a question for each company and its legal advisers; our part is to make the technical facts available quickly and accurately.

Learning from every incident

Revision 3 moves improvement beyond a single meeting at the end and spreads it across the whole incident lifecycle ². A structured review still has its place. The practitioner guide lists questions such as what exactly happened and when, whether documented procedures were followed, what information was needed sooner, and which corrective actions could prevent a repeat ⁴. It recommends feeding the answers into updated playbooks, detection rules and training, and, where gaps are systemic, into changes to security architecture ⁴.

People and access: the internal side

Not every breach starts outside. In EMEA, 29% of breaches originated within the organisation, with 19% attributed to unintentional mistakes ⁵. That share needs some context: Verizon also reports that the number of insiders involved fell by 41%, and attributes the decline to other breach types growing faster ⁵. Verizon's EMEA lead pointed to employee training, robust access controls and zero-trust frameworks as responses ⁵.

For any team that works with external specialists, we see this as a reason to treat access management as part of onboarding and offboarding, with clear scopes and regular reviews.

How we approach it

When we support live products, we treat maintenance, updates and incident readiness as one continuous practice rather than three separate projects. That means a regular update cadence, monitoring with clear escalation rules, named responsibilities, and reporting that shows product owners what changed and why. The practitioner guidance we have drawn on puts the greatest weight on preparation ⁴, and NIST's revision places that preparation within everyday risk management ⁸. A product that is looked after this way after launch is one that its users, and the team behind it, can keep relying on.

Sources

1. NIST Revises SP 800-61: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, nist.gov, Apr 3, 2025
2. Updated NIST Incident Response Guidance: SP 800-61 Rev. 3 - Tandem, tandem.app, Jul 11, 2025
3. NIST SP 800-61 Rev. 3: Incident Response Guidance · Guide | Sefism, sefism.com, Sep 23, 2026
4. NIST Incident Response Framework: SP 800-61 Explained, bellatorcyber.com, Jan 23, 2026
5. Verizon’s 2025 Data Breach Investigations Report: System intrusion breaches double in EMEA | About Verizon, verizon.com, Apr 23, 2025
6. Verizon’s 2025 Data Breach Investigations Report: Alarming surge in cyberattacks through third-parties | About Verizon, verizon.com, Apr 23, 2025
7. NIST Revises SP 800-61 | CSRC, csrc.nist.gov, Apr 2, 2025
8. Incident Response | CSRC | CSRC, csrc.nist.gov, Feb 29, 2024