Security Incident Handling
2 min read
last change: 9-6-2023
Security Incident
A Security Incident is any event where a person or a system gained more access to data then would be appropriate considering the given authorisation level. Such an incident can be triggered due to conscious actions, when a person or a system deliberately tries to find holes in the security system, or unconscious, where access is given due to faulty configuration or setup of systems.
Security Incidents should always be logged by the ShipitSmarter employee that first noticed the incident in the form of creating a bug on the Kanban board. Part of the bug entry is the classification of the incident:
Information Security Incident Classification
| severity | description | |
|---|---|---|
| 1 | Critical | Unidentified or identified people or systems are actively abusing the system with data becoming publicly available, data getting destroyed or manipulated outside system functionality or sabotaging system functionality. |
| 2 | High | Unidentified people or systems can use functionality and manipulate data outside their intended scope. |
| 3 | Medium | Identified people or systems can use functionality and manipulate data outside their intended scope. |
| 4 | Low | Identified people or systems can read data that is outside their intended scope. |
What to do
How to act when a Security Incident has been noticed:
- Contact the Operators through Teams to understand if the issue is known.
- When the issue is not known, create a bug or issue on the kanban board.
- Add a tag to the bug: “security incident”.
- Mention the Data Protection Officer in the description, so the DPO is informed.
- Follow the normal bug procedure, so security incidents are solved according to the SLA.
published on: 9-6-2023