A cyber security incident is anything that puts your product’s data or service at real risk: an API key pushed to a public repository, a customer account taken over, a database left open to the internet, a developer laptop with production access stolen. A small product team doesn’t need a separate incident department. It needs one page that says who decides, what gets switched off first, who gets told and how the team learns from it. This article gives you that page.
NIST, the US standards body, uses this definition in its incident response guide: an occurrence that actually or imminently jeopardizes the integrity, confidentiality or availability of information or an information system, or that breaks or threatens to break the law or your security policies. In plain words, someone can see, change or block something they shouldn’t, or is about to.
| What happened | Incident? | First move |
|---|---|---|
| An API key was pushed to a public code repository | Yes | Revoke the key and issue a new one, then check what it was used for |
| A customer says someone else is logged into their account | Yes | Lock the account and end all its sessions |
| A bug shows one customer’s data to another customer | Yes | Turn the feature off, then find out who saw what |
| A laptop with production access is lost or stolen | Yes | Revoke that person’s sessions, keys and access |
| Server load jumps at 3 a.m. for no known reason | Treat it as one until explained | Check monitoring and logs before anything else |
| A phishing email reached staff and nobody clicked | No | Log it and warn the team |
In April 2025 NIST replaced its 2012 incident guide with SP 800-61 Revision 3. The older version described a cycle of four phases: preparation, detection and analysis, containment with eradication and recovery, and post-incident activity. The first version of this article followed that cycle.
The new version maps incident response onto the six functions of the NIST Cybersecurity Framework 2.0. Govern, Identify and Protect are the preparation. Detect, Respond and Recover are the response itself. NIST also notes that incidents now happen often, recovery can take weeks or months, and lessons should often be shared as soon as they are found, not held until recovery ends.
For a small team the practical message is the same: most of the work happens before the incident, and the response goes faster when the decisions are already made.
Software flaws have overtaken stolen passwords. Verizon’s 2026 Data Breach Investigations Report says 31% of breaches now start with a software vulnerability, ahead of stolen passwords as the most common way in, and 48% of breaches involve ransomware. IBM’s Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, 12% more than a year earlier.
For a small product team that means two habits matter more than before. Keep servers, libraries and plugins patched, and know which of them face the internet. And keep backups that ransomware can’t reach, so recovery doesn’t depend on paying anyone.
Four jobs need an owner during an incident. In a team of five, one person can hold two of them, but the lead shouldn’t also be the person fixing the servers.
| Role | Usually | Job |
|---|---|---|
| Incident lead | Founder, CTO or head of product | Decides what to switch off, who to tell and when the incident is over |
| Responder | A developer, or your agency’s engineer | Contains the problem, finds the cause, fixes it and restores data |
| Communicator | Founder or head of support | Talks to customers, partners and, if needed, the regulator |
| Note-taker | Anyone not fixing things | Keeps the timeline: what was seen, decided and done, with times |
An afternoon of work covers most of this.
Rules on reporting differ by country, so check yours with a lawyer. As one example, the UK regulator’s guidance says you must report a notifiable personal data breach without undue delay and not later than 72 hours after becoming aware of it. If the breach is likely to put people at high risk, you must also tell them directly and without undue delay. The same guidance asks you to record every breach, including the ones you don’t have to report. And if a supplier that processes data for you, such as a hosting provider or a development agency, suffers a breach, it must inform you without undue delay.
The clock starts when you become aware, so the incident lead should know this rule before an incident starts.
The first question in any incident is what changed, and when. Products that keep their history can answer it quickly.
On Koncierge, a payment platform for Japan, records are never erased, so the history of every payment stays complete. The IPOPBOOKS admin panel keeps a log of every posted entry, and an hourly check makes sure the books still balance. Records like these turn “we think something changed” into a list of exact changes.
If you inherited a product and don’t know what is in it, start with an audit. Our code audit costs a fixed $3,500 and takes 5 working days. It lists every account the product depends on and whose name it is in, and ranks the security problems it finds with the worst first.
If you’re planning a new product, put these controls into the scope from the start. Our free project estimate turns your brief into user stories that you confirm, so two-factor login, backups and monitoring show up in the budget as their own lines instead of as extra work after launch.
NIST defines it as an occurrence that actually or imminently jeopardizes the integrity, confidentiality or availability of information or a system, or breaks or threatens to break the law or security policies. For a product team, that means a leaked key, a taken-over account, exposed data or an outage caused by an attack.
A data breach is one kind of incident. The UK regulator defines a personal data breach as a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. An outage caused by an attack is an incident even when no data leaks.
It depends on where you and your users are. In the UK, a notifiable personal data breach must be reported to the regulator without undue delay and not later than 72 hours after you become aware of it. Check the rules for your countries with a lawyer before an incident happens.
Yes, and one page is enough: who leads, who to call, what to switch off first and how to restore from backup. Writing it takes an afternoon. Working it out during an incident takes much longer.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.