Skip to content

Information Security Event Reporting Procedure

Purpose. Security events only get handled if people report them fast. This procedure gives everyone at Soon one clear channel and one simple rule: if something looks off, report it immediately — you will never be blamed for a good-faith report.

1. Scope

All Soon employees and contractors, for any observed or suspected information security event affecting Soon systems, devices, data, or suppliers. Handling of confirmed incidents is out of scope (see Section 2.3).

2. Procedure

2.1 Reporting channels (confirmed 2026-07-03)

Every event is reported through two channels used together:

  1. Slack, for speed. Post in the channel matching the issue and always @-mention the channel or specific people so it isn't missed:
Event type Slack channel
Suspected security incident, phishing, credential compromise, data exposure #Security
Infrastructure, cloud account, or availability issue #DevOps
Vulnerability or issue found in the codebase or a product feature #Development
Anything else / unsure #General
  1. Email (security@soon.works), for the record. This creates the paper trail — what was reported, when, and by whom. Send it in addition to the Slack post, not instead of it.

For urgent situations (an event is happening now or is imminent), post in Slack immediately with an @-mention — don't wait to compose a careful message; follow up with the email record afterwards. Do not sit on it, investigate it yourself, or wait for confirmation that it is "real". Report first.

2.2 What to report, and when

Report immediately — within minutes of noticing, not at end of day — anything suspicious, including:

  • Phishing or other social engineering attempts (email, Slack, Intercom, SMS, calls).
  • Lost or stolen device used for work (laptop, phone).
  • Suspected account compromise — unexpected MFA prompts, sign-in alerts, sessions you don't recognise on Google/GitHub/AWS or any work app.
  • Data-exposure mistake — customer data sent to the wrong recipient, a file or bucket shared too widely, credentials committed to a repo.
  • Supplier breach notification — any security notice from AWS, GitHub, Stripe, Intercom, Sentry, PostHog, Netlify, or another supplier.
  • Anything else that feels wrong — unexpected system behaviour, alerts in Sentry/CloudWatch that suggest misuse, a colleague's account acting oddly.

Include what you saw, when, on which system, and what (if anything) you already did. No blame: good-faith reports — including reporting your own mistake — never lead to negative consequences. Fast self-reporting is exactly what we want.

2.3 What happens next

  1. The security responsible acknowledges the report (same working day) and triages it: false alarm, event to monitor, or incident.
  2. If it is an incident, it is escalated to incident response. Handled under the Information Security Incident Response Procedure, which is written. (Superseded note: it was previously listed as not yet written — see ROADMAP.md; until it exists, the security responsible coordinates response directly with Olaf Jacobson.
  3. The reporter is told the outcome. Events and outcomes are logged so trends (e.g. repeated phishing waves) are visible at management review.

3. Roles & responsibilities

  • Everyone — reports events immediately via the channels in 2.1.
  • Security responsible — acknowledges, triages, logs, and escalates; monitors the channel.
  • Olaf Jacobson (management) — decides on escalation of major events and on any customer or authority notification (with the Privacy and Personal Data Protection Policy for personal-data breaches).

Change log

Version Date Author Comments
0.1 2025-06-07 Olaf Jacobson First draft document
0.2 2026-07-03 Olaf Jacobson Replaced generic help-desk/location-security template content with Soon's actual reporting workflow: Slack (channel by issue type, always @-mention) + email for the paper trail
0.3 2026-07-18 Andrea Cardinali Rewritten lean (ISMS overhaul), preserving the confirmed Slack + security@soon.works reporting workflow