When to call police or your national CSIRT after a cyber incident

TL;DR — After a cyber incident, involve the police when there is extortion, fraud, theft, credible threats, or major business harm from a crime. Involve your national CSIRT (Computer Security Incident Response Team) when you need technical coordination, broader threat intelligence, or help containing an attack that may affect others; in many cases you contact both, but first preserve evidence and stop ad-hoc cleanup. Reading time: ~7 min

What it is and where it sits

Two outside parties are commonly confused after an incident:

• Police: law enforcement that investigates crimes, gathers evidence for prosecution, and may issue case numbers, preservation requests, or formal evidence handling instructions.
• National CSIRT (Computer Security Incident Response Team): a country-level incident response body that helps organizations understand, contain, and coordinate around cyber threats. They are usually not there to arrest anyone; they are there to reduce harm and share technical indicators (signs of compromise like bad IPs, domains, file hashes).

They sit outside your normal software stack. They are not part of your hosting provider, your software agency, or your cyber insurer, though all of those may tell you when to contact them.

In a typical incident flow, your own team and vendors detect something first: suspicious logins, ransomware notes, fake invoices, data exfiltration (data copied out), or a website defacement. Then you decide whether the event is:

1. a technical problem you can handle internally,
2. a legal/criminal matter for police,
3. a coordinated cyber defense matter for the national CSIRT,
4. or all of the above.

[Users] ---- 1. normal traffic ----> [Website/App]
                                      |
                                      | 2. logs, alerts, backups
                                      v
                               [Your Team / MSP]
                                      |
                    3a. crime report  |  3b. technical incident report
                                      v
                                  [Police]      [National CSIRT]
                                      ^             ^
                                      | 4. evidence | 4. IOCs, guidance
                                      |             |
                               [Cloud/Email/DNS Providers]

What they replace: neither replaces your own incident response. The police do not replace your IT team. The CSIRT does not replace your lawyer, insurer, or regulator notifications. They are additional lanes for specific needs.

Where they live in the request/data flow: nowhere in the live request path. They are part of the response path after detection. The practical architecture context is this: your app, email, DNS, cloud storage, identity provider (login system), and endpoint devices generate evidence. That evidence may later be shared with police or CSIRT.

How it actually works

Here is one realistic end-to-end example: your finance manager receives a ransom email claiming the attacker stole customer files from your cloud storage and will publish them unless you pay.

Step 1: Confirm whether this is only spam or a real incident

Start in the dashboards you already have:

• In your cloud provider's dashboard, open the storage bucket or file share access logs.
• In your identity provider dashboard (for example, the place where you manage employee logins), open sign-in logs and filter for the user named in the extortion email.
• In your email admin dashboard, open the original message headers and delivery details.

You are looking for concrete signs: unusual downloads, impossible-travel logins, disabled multi-factor authentication, new API keys, or forwarding rules.

Step 2: Preserve evidence before cleanup

⚠️ If you delete accounts, rotate every key immediately, or wipe a server before collecting basic evidence, you may lose the timeline you need for insurance, legal reporting, police, or your own root-cause analysis.

Literal actions:

• Export the suspicious email as an .eml file from your mail client or admin console.
• Export sign-in logs as CSV from the identity dashboard.
• Export cloud audit logs covering at least 7 days before the first suspicious event.
• Take screenshots of ransom notes, admin pages, and alerts, but do not rely on screenshots alone; export the raw logs too.
• Write down the current time zone used by each system so timestamps can be matched later.

Step 3: Contain the incident

Now do the minimum needed to stop further harm:

• In your identity dashboard: revoke active sessions for the affected user.
• Reset the affected password.
• Re-enroll multi-factor authentication if it was changed.
• Disable suspicious API keys or access tokens.
• If a public server is actively serving malicious content, put it behind a maintenance page or remove the bad content.

This is the point where many organizations ask, "Do we call police, CSIRT, or neither?"

Step 4: Decide who to contact

In this example, the attacker claims theft and demands money. That strongly points to both:

• Police, because extortion is a crime and there may be payment instructions, wallet addresses, phone numbers, or mule bank accounts they can correlate with other cases.
• National CSIRT, because they may recognize the campaign, tell you whether the threat actor is bluffing, provide known indicators, and warn if the same attack is hitting others in your sector.

Step 5: What each party will usually ask for

Police typically want:

• what happened,
• when you discovered it,
• what systems were affected,
• estimated financial loss or business impact,
• copies of extortion messages,
• payment instructions or cryptocurrency wallet addresses,
• contact details for a technical lead.

A national CSIRT typically wants:

• affected domains, IP addresses, and email addresses,
• suspicious file hashes (unique file fingerprints),
• attacker infrastructure like domains or URLs,
• relevant log excerpts with timestamps,
• whether the incident is ongoing,
• whether other organizations may be affected.

Step 6: Continue your own response in parallel

Neither call pauses your obligations. You still need to:

• assess whether personal data was involved,
• notify your insurer if you have cyber coverage,
• ask legal counsel whether breach notification laws apply,
• restore safely from backups only after the access path is closed.

The key mechanism is simple: police handle the criminal case; CSIRT handles technical coordination and ecosystem defense; your team handles containment and recovery.

When to use it (and when not to)

Use this as a practical decision table.

You probably don't need this if...

• the event is a routine spam/phishing email that no one clicked,
• an antivirus tool blocked malware and you have no evidence of execution or spread,
• a user forgot a password and mistook the lockout for hacking,
• a website bug caused an outage but there is no sign of unauthorized access.

A good test: if you cannot yet describe a crime, a serious attempted crime, or a technically significant compromise, start with your internal team, hosting provider, or software agency first.

Trade-offs

Every escalation helps in one way and costs in another.

The main trade-off is operational focus. Escalate too late and you lose help. Escalate too early, without basic facts, and you create churn while your systems are still exposed.

In practice

Below are two practical examples you can adapt today: one for preserving evidence from a web server, and one for packaging a simple incident summary for police or CSIRT.

⚠️ Log rotation and cleanup jobs can overwrite evidence. Before changing server settings or restarting services, copy the current logs to a separate folder or download them from your provider's dashboard.

Example 1: Copy web server logs before you restart anything

Dashboard path first: in your hosting provider's dashboard, open the server or app service, then Logs or Access Logs, and download the relevant time range as a file. If your provider exposes a terminal and you are comfortable using it, this command copies common nginx logs to an evidence folder.

mkdir -p ~/incident-evidence/nginx-2026-10-30 && \
cp /var/log/nginx/access.log* ~/incident-evidence/nginx-2026-10-30/ && \
cp /var/log/nginx/error.log* ~/incident-evidence/nginx-2026-10-30/

What it does: creates a dated evidence folder and copies current and rotated nginx logs into it. Gotcha: if your server uses a different path or a managed platform, these files may not exist locally; use the provider's log export instead of guessing.

Example 2: Create a clean incident summary JSON to send internally or attach to a report

You can draft this in any text editor and attach it to your ticket, insurer notice, police report, or CSIRT intake form.

{
  "incident_title": "Extortion email claiming stolen customer files",
  "detected_at_utc": "2026-10-30T09:15:00Z",
  "reported_by": "finance-manager@example.com",
  "systems_in_scope": ["Microsoft 365", "cloud storage", "customer portal"],
  "known_indicators": {
    "sender_email": "attacker@protonmail.example",
    "wallet_address": "bc1example...",
    "suspicious_ips": ["198.51.100.24"],
    "domains": ["paste-example.example"]
  },
  "business_impact": "Possible data theft claim; no confirmed encryption; finance team disrupted",
  "actions_taken": [
    "Exported email as EML",
    "Revoked user sessions",
    "Reset password",
    "Exported sign-in logs and storage audit logs"
  ],
  "open_questions": [
    "Was data actually exfiltrated?",
    "Was MFA changed or bypassed?"
  ],
  "primary_contact": {
    "name": "Jane Smith",
    "role": "Operations Manager",
    "email": "jane.smith@example.com",
    "phone": "+1-555-0100"
  }
}

What it does: gives responders a structured summary with facts, indicators, and actions taken. Gotcha: do not guess. If a field is unknown, write "unknown" or remove it; wrong certainty wastes time.

Example 3: Preserve an email with full headers using a mail client export

If your mail system offers "Show original" or "View source", use that and save the raw message. If you already have the raw message in a file, keep it unchanged and record its checksum (integrity fingerprint).

sha256sum ransom-message.eml

What it does: calculates a SHA-256 checksum so you can later prove the file was not altered. Gotcha: do not open and resave the .eml in a different editor before hashing it, or the checksum may change.

Further reading

• NIST Computer Security Incident Handling Guide (SP 800-61)
• FIRST CSIRT Services Framework
• The "Reporting cybercrime" guidance from your national police or cybercrime unit
• The incident reporting section of your national CSIRT's official website
• The "Security Breach Notifications" guidance from your data protection authority

This article was written by an AI system and published pending human review. Verify anything you intend to act on.