Incident response: preparation, containment and reporting in Norway
A response plan should identify who can act, how evidence is preserved and which notifications apply. The first decisions depend on the incident, not a fixed script.
The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.
Incident response is the organised work of assessing a suspected security event, limiting harm, restoring services and learning from what happened. It begins before an alert, with agreed responsibilities and access to the tools and contacts needed to act.
NIST’s incident response guidance places this work within wider risk management. For a business, the immediate benefit of preparation is straightforward: responders can make decisions without first inventing their authority.
Establish facts and ownership early
Name an incident lead and open a timeline with timestamps and time zones. Record observations, actions, uncertainties and who made each decision. Keep communications available through a trusted channel if the normal email or identity system may be compromised.
A blocked attachment is not automatically a serious incident, but neither should it be dismissed without context. Check whether related activity occurred, whether anything executed and whether the control worked as expected. Classify the event using its effect and the applicable reporting rules.
Contain according to the situation
Isolation, session revocation and access restrictions can limit further activity. Assess operational consequences, particularly for critical services or safety-related systems. Pre-authorised actions help responders move quickly where the consequences are understood.
Preserve relevant logs and, where appropriate, volatile evidence. Powering off a machine can destroy useful information, but leaving it running can also permit continuing harm. The right choice depends on containment options and the incident. Avoid a universal rule that prevents responders from protecting people or essential services.
Changing a password may not invalidate every session or token. Identify the credentials and sessions the attacker could use, revoke them where needed and close the original access path.
Assign communication and recovery
Technical responders investigate and contain. Management authorises consequential business decisions. Privacy, legal and communications owners assess their respective obligations.
Recovery should use trusted systems and account for persistence, compromised credentials and the vulnerability that enabled access. Verify essential functions before declaring normal operations restored. A completed restore does not prove that stolen data was never accessed or copied.
Apply the correct reporting rule
For a personal data breach, the controller must generally notify Datatilsynet without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to people’s rights and freedoms. The exception is not simply “low risk means no report.” Document the assessment. Datatilsynet explains the threshold and staged reporting.
Other duties depend on the entity and event. Covered financial firms should use Finanstilsynet’s DORA reporting guidance. Organisations within the Digital Security Act should check NSM’s guidance. Contracts, insurance terms and other sector rules may create additional notification duties.
Do not wait for a final forensic report before assessing these obligations. Equally, do not apply every deadline to every alert.
Exercise the handoffs
Walk through an incident with the people named in the plan. Can they reach the provider, authorise containment, retrieve evidence and contact the right decision-makers?
Managed detection and response can supply detection and response capacity within its scope. It does not automatically include full forensics, recovery or external communication. Record those boundaries and address gaps before an incident tests them.
