When a company experiences a deviation or security breach, the biggest problem is usually not just the event itself. The real risk arises when no one knows what to do, who decides, and how the situation is documented. ISO 27001 doesn’t require perfection but a controlled way to detect, handle, and prevent similar events in the future.
This article explains what deviations and security breaches mean in practice, how they relate to ISO 27001 requirements, and how to build a working handling model for SMEs. You’ll also get a clear step-by-step path you can apply immediately in your management system.
What Do Deviations and Security Breaches Mean in Practice?
A deviation means a situation where an agreed procedure, requirement, or control is not fulfilled. For example, an employee’s access rights were not removed within 24 hours of employment termination, even though this is the guideline.
A security breach is a more severe deviation where the confidentiality, integrity, or availability of information is compromised. Examples include customer data sent to the wrong recipient, ransomware on a server, or downtime of a critical system.
In practice, companies should distinguish at least these cases:
| Situation | Example | Impact | Handling Time |
|---|---|---|---|
| Deviation | Backup check was missed | Potential risk, no immediate harm | Handling to start within 5 business days |
| Serious deviation | Admin account without multi-factor authentication | Increased risk of misuse | Handling to start within 24 hours |
| Security breach | Malware encrypts files | Direct impact on availability | Respond immediately, within 1 hour |
| Personal data breach | Customer list sent to wrong recipient | Potential GDPR notification obligation | Assessment immediately, often within 72 hours |
Many SMEs lump all events under the word “incident.” This blurs urgency, responsibilities, and reporting. Ask yourself: does your staff recognize when it’s an ordinary deviation and when it’s a security breach?
Note
ISO 27001 does not require that deviations or security breaches never happen. Instead, it requires the organization to have a repeatable way to identify events, respond to them, fix root causes, and demonstrate this in audits.
Why Does ISO 27001 Emphasize the Handling Process, Not Just the Reaction?
ISO 27001 is based on continuous improvement. Therefore, a single event is not just a “fire to put out” from the standard’s perspective but also a signal that some control, instruction, or division of responsibility isn’t working well enough.
Good deviation management provides at least three benefits:
- you identify recurring issues before they become serious
- you can demonstrate to management and customers that the situation is under control
- you gain material for improving risk assessments and controls
If handling is only a technical reaction, learning is lost. For example, a server can be restored from backup in 4 hours, but if no one investigates why the restore was needed, the same event can happen again next month.
In an ISO 27001 environment, you should at least document these:
- what constitutes a deviation
- what constitutes a security breach
- who receives notifications
- who decides on escalation
- timeframe to start handling
- how the event is documented and closed
A Practical Handling Model for SMEs
SMEs don’t need a heavy SOC operation or complex ticketing system. Often, a clear model with agreed notification channels, responsibilities, classification, and post-handling suffices.
A simple model usually works better than a fancy but unused process. If staff can’t recall the procedure in 30 seconds, it’s probably too complicated.
Below is a practical responsibility model you can adapt:
| Role | Responsibility for deviation | Responsibility for security breach | Target Time |
|---|---|---|---|
| Staff | Report observation | Report immediately and preserve evidence | Within 15 minutes of noticing |
| IT / system administrator | Assess technical impact | Isolate, contain, restore | Start within 1 hour |
| Information security officer / designated person | Classify and document | Coordinate handling and reporting | Classification within 4 hours |
| Management | Approve corrective actions | Decide communication and resources | Decisions within 24 hours |
Concrete minimum for SMEs:
- one notification channel, e.g., a dedicated email or form
- one designated person and one substitute
- one classification model, e.g., low–medium–high
- one deviation register where all cases are logged
Tip
Test your notification channel immediately. Send a test message and ensure the responsible person acknowledges it within 15 minutes during working hours. No acknowledgment means the process isn’t working yet.
Define Notification Channel and Classification Rules
Choose one primary method for reporting deviations or security breaches. Record three classes, for example low, significant, and critical, with clear criteria such as impact on customers, length of downtime, and volume of personal data involved.
Respond Quickly and Limit Damage
Once a notification arrives, the first goal is to prevent worsening. This may involve disabling user accounts, disconnecting devices from the network, contacting the wrong recipient, or restoring service via backup procedures within 1–4 hours depending on severity.
Document Event Details Immediately
Record at least what happened, when it was detected, whom it affected, which systems were involved, and initial actions taken. Don’t postpone documentation to the next day, as the timeline blurs quickly within 2–3 hours.
Identify Root Cause and Decide Corrective Actions
Once stable, investigate why the event occurred. Review missing controls, unclear instructions, training gaps, or technical faults and assign responsible owners and deadlines, such as 14 or 30 days, for each corrective measure.
Close the Case Only After Learning is Implemented
Don’t mark the case closed immediately after technical fixes. Close it only once corrective actions have been completed, impact verified, and if needed, risk assessments, instructions, or training updated.
What Should You Record in the Deviation Register?
Many companies make the mistake of logging only a title and date. This is of little value in audits or internal development. A good deviation register helps identify if the same issue recurs, e.g., in access rights, suppliers, or backups.
Log at least the following for each case:
- ID or case number
- date and time of observation
- reporter
- classification and severity
- affected target, e.g., customer data, service, or device
- immediate actions
- root cause
- corrective actions
- responsible person
- due date
- closing date
To make the register a real management tool, add these two metrics:
| Metric | Calculation | Target Level |
|---|---|---|
| Response time | Time from observation to first acknowledgment | Under 1 hour in critical cases |
| Closure time | Time from observation to completion of corrective actions | 14–30 days for normal deviations |
| Recurrence | Number of same type cases within 12 months | Max 1–2 repeats per root cause |
| Late actions | Percentage of corrective actions overdue | Under 10% |
With these, management can quickly see if the process is genuinely controlled or just on paper.
Common Mistakes in Handling Deviations
Surprisingly often, the problem is not technical but organizational. The event is noticed but owned by no one. The result is a rushed fix, but the root cause remains.
Avoid these especially:
- not logging deviations if “fixed quickly”
- confusing security breaches with normal outages
- documenting corrective actions too vaguely, e.g., “improve instructions”
- setting no deadlines or failing to track them
- management getting information only afterward
Concrete example: employee sends a quote to the wrong customer. If the case is closed with just a reminder to “be more careful,” nothing really changes. Better corrective actions could include:
- implementing recipient confirmation for external communications
- updating instructions within 7 days
- training the sales team at the next weekly meeting
- monitoring similar errors for 3 months
Warning
A common mistake is closing the case as soon as the technical problem is fixed. In an audit, this quickly shows: the event is recorded, but root cause, corrective action, and impact evaluation are missing.
How to Link Deviations and Breaches to Continuous Improvement?
The value of ISO 27001 comes from each case improving the entire information security management system. Every significant deviation tells you something about risk assessment, control effectiveness, or staff guidance.
In practice, after handling, review at least these four points:
- does the risk assessment need updating
- should a control be added or tightened
- should instructions or processes be updated
- is targeted training needed for a specific team
A good monthly rhythm for SMEs may be:
| Frequency | Activity | Duration |
|---|---|---|
| Weekly | Review open cases with responsible person | 15–30 min |
| Monthly | Analyze trends and overdue actions | 30 min |
| Quarterly | Evaluate recurring root causes and update risks | 60 min |
| Annually | Utilize findings in management reviews and internal audits | 1–2 h |
If you use Tietoturvapankki, tracking deviations, corrective actions, and responsibilities is easier to link with risk management, documentation, and ISO 27001 requirements. This reduces the common problem where information remains scattered in emails, Excel sheets, or individual memories.
Getting Started Without a Heavy Project
If your company doesn’t yet have a clear model, don’t try to build everything at once. Start small but complete it. Within a month, you can have a functional basic level.
Start list for the next 30 days:
- appoint responsible and backup persons
- define one notification channel
- create a simple classification table
- implement a deviation register
- agree on handling times, e.g., 1 hour, 24 hours, and 30 days
- handle the first cases with this model
This already ensures deviation handling is not random. Afterwards, you can deepen processes into supplier management, personal data breach assessments, and technical monitoring alerts.
Summary
- Deviation and security breach should be distinguished as their urgency, impact, and reporting needs differ.
- A working ISO 27001 model includes notification channel, classification, responsibilities, deadlines, and deviation register.
- Cases should be closed only after root cause is identified and corrective actions implemented.
- Track at least response time, closure time, recurrence, and overdue actions.
- SMEs can start lightly if the process is clear and consistently applied.
Need help with information security management?
Our experts are here to assist you.