1. Purpose
The Security Violation Classification Matrix provides a consistent method for classifying suspected or confirmed information-security violations.
The matrix helps the organization determine:
- What type of violation occurred
- Whether the violation is accidental or intentional
- The severity of the violation
- The security impact
- The information or systems affected
- Whether the matter should be treated as a security incident
- Whether HR, Legal, Privacy, Compliance, or Management involvement is required
- The appropriate response and escalation level
- Whether corrective action, disciplinary action, or risk treatment is required
Core Principle
Identify → Classify → Assess Intent → Assess Impact → Determine Severity → Escalate → Respond → Record → Review
2. Scope
This matrix may be used for violations involving:
☐ Employees
☐ Contractors
☐ Consultants
☐ Interns
☐ Temporary personnel
☐ Privileged users
☐ Remote workers
☐ Third-party personnel where applicable
It may apply to violations involving:
- Information
- Applications
- Cloud systems
- Production environments
- Source code
- Databases
- Endpoints
- Identity systems
- Security controls
- Customer information
- Personal data
- Confidential information
- Restricted information
3. Classification Principles
Classification should be based on evidence and should consider:
- What happened?
- What requirement was violated?
- What information or system was affected?
- Was the activity authorized?
- Was it accidental or intentional?
- What was the actual impact?
- What could have happened?
- Was the person trained?
- Was the behavior repeated?
- Were security controls bypassed?
- Was there an attempt to conceal the activity?
- What response is proportionate?
Classification should not be based solely on the job title or seniority of the person involved.
4. Violation Categories
Classify the primary violation category.
| Code | Category | Examples |
|---|---|---|
| SV-01 | Unauthorized Access | Accessing systems or information without authorization |
| SV-02 | Credential Misuse | Sharing or using another person’s credentials |
| SV-03 | Privileged Access Misuse | Improper use of administrative access |
| SV-04 | Information Misuse | Unauthorized copying, disclosure, transfer, or use |
| SV-05 | Data Protection Violation | Improper handling of personal/customer data |
| SV-06 | Security Control Bypass | Circumventing approved security controls |
| SV-07 | Password/MFA Violation | Sharing passwords, MFA codes, or bypassing authentication |
| SV-08 | Technology Misuse | Unauthorized software, cloud service, device, or tool |
| SV-09 | Security Configuration Violation | Unauthorized security configuration changes |
| SV-10 | Logging/Monitoring Violation | Disabling or bypassing security monitoring |
| SV-11 | Incident Reporting Violation | Failure to report a known security incident |
| SV-12 | Policy/Procedure Violation | Failure to follow approved security requirements |
| SV-13 | Data Retention/Disposal Violation | Improper retention or disposal |
| SV-14 | Physical Security Violation | Unauthorized physical access or security bypass |
| SV-15 | Source Code/Development Violation | Unauthorized code access or insecure development activity |
| SV-16 | Cloud Security Violation | Unauthorized cloud activity or configuration |
| SV-17 | Security Testing Violation | Unauthorized testing or scanning |
| SV-18 | Evidence/Investigation Violation | Destruction, alteration, or concealment of evidence |
| SV-19 | Repeated Non-Compliance | Repeated failure to comply with security requirements |
| SV-20 | Other | Other security-related violation |
5. Classification Status
Every reported matter should initially be classified as:
☐ Suspected Violation
☐ Under Investigation
☐ Confirmed Violation
☐ Violation Not Confirmed
☐ Security Incident
☐ Privacy Incident
☐ Policy Non-Compliance
☐ Human Error
☐ No Violation
☐ Further Investigation Required
A preliminary classification may be changed when additional evidence becomes available.
6. Intent Classification
Determine the apparent intent based on available evidence.
| Level | Classification | Description |
|---|---|---|
| I-1 | Accidental | Activity occurred unintentionally |
| I-2 | Human Error | Person failed to follow a requirement without evidence of deliberate misconduct |
| I-3 | Negligent | Reasonable security care was not exercised |
| I-4 | Reckless | Significant disregard for known security requirements |
| I-5 | Intentional | Requirement was knowingly violated |
| I-6 | Malicious | Activity appears intended to cause harm, obtain unauthorized benefit, or compromise security |
| I-0 | Unknown | Evidence is insufficient to determine intent |
Important
Intent should not be inferred simply because a security control was violated.
For example:
A developer accidentally commits a secret to a private repository.
This may be a security violation, but it should not automatically be classified as intentional misconduct.
7. Information Sensitivity
Classify the highest information level affected.
| Level | Information | Examples |
|---|---|---|
| L1 | Public | Public website content, published material |
| L2 | Internal | Internal procedures, general business information |
| L3 | Confidential | Business plans, internal security information, customer business information |
| L4 | Restricted | Credentials, sensitive personal data, production secrets, highly sensitive customer information |
Where multiple classifications are affected, use the highest applicable classification.
8. System Criticality
Classify the affected system.
| Level | System | Example |
|---|---|---|
| S1 | Low | Non-critical internal application |
| S2 | Important | Business application |
| S3 | High | Customer-facing application |
| S4 | Critical | Production infrastructure, identity system, critical database |
9. Access Level
Consider the highest access involved.
| Level | Access |
|---|---|
| A1 | Standard user |
| A2 | Sensitive information |
| A3 | Customer/personal data |
| A4 | Source code/cloud administration |
| A5 | Production/privileged/database/security administration |
Higher access generally increases the potential severity of the violation.
10. Impact Classification
Assess actual impact.
| Level | Impact | Typical Characteristics |
|---|---|---|
| IMP-1 | Minimal | No meaningful security impact |
| IMP-2 | Low | Limited internal impact |
| IMP-3 | Moderate | Significant internal or limited external impact |
| IMP-4 | High | Significant customer, business, security, or privacy impact |
| IMP-5 | Severe | Major compromise, significant data exposure, major service impact, or serious regulatory/contractual consequences |
Assess separately:
☐ Confidentiality
☐ Integrity
☐ Availability
☐ Privacy
☐ Customer impact
☐ Financial impact
☐ Regulatory impact
☐ Contractual impact
☐ Reputational impact
11. Potential Impact
Actual impact may be low even when potential impact is high.
Therefore assess:
Actual Impact: __________
Potential Impact: __________
Example:
A developer accidentally executes a privileged production command but the command makes no changes.
- Actual impact: Low
- Potential impact: High
The event should therefore receive appropriate investigation even though no significant damage occurred.
12. Frequency Classification
Determine whether the matter is:
☐ First occurrence
☐ Previous similar occurrence
☐ Repeated occurrence
☐ Persistent non-compliance
☐ Pattern across multiple personnel
Repeated behavior may increase the required response.
13. Control Bypass Classification
Determine whether existing security controls were:
☐ Followed
☐ Accidentally bypassed
☐ Circumvented
☐ Disabled
☐ Deliberately defeated
☐ Not available
☐ Ineffective
☐ Unknown
A deliberate attempt to defeat security controls generally requires enhanced review.
14. Concealment Assessment
Assess whether there was an attempt to conceal the activity.
☐ No concealment
☐ Activity not recognized as requiring concealment
☐ Possible concealment
☐ Evidence deleted
☐ Logs modified/deleted
☐ Activity intentionally hidden
☐ False information provided
☐ Unknown
Evidence of deliberate concealment should generally increase the investigation severity.
15. Severity Levels
The organization may use four primary severity levels.
| Severity | Description |
|---|---|
| Low | Limited violation with minimal impact and low risk |
| Medium | Meaningful violation with moderate risk or potential impact |
| High | Significant violation involving sensitive information, privileged access, serious control bypass, or material impact |
| Critical | Major or deliberate violation with severe security, customer, privacy, regulatory, financial, or operational consequences |
16. Low Severity
Typical characteristics:
- Limited scope
- Low sensitivity information
- No significant impact
- No privileged access
- No evidence of intentional misconduct
- First occurrence
- Easily corrected
Examples
- Accidental use of an unapproved file-sharing method for non-sensitive internal information
- Minor policy deviation with no material security impact
- Failure to complete a routine security task within the required period
Typical Response
☐ Informal correction
☐ Additional awareness
☐ Training
☐ Access/process correction
☐ Record where required
☐ Monitor for recurrence
17. Medium Severity
Typical characteristics:
- Moderate information sensitivity
- Meaningful control violation
- Repeated or negligent behavior
- Potential customer or security impact
- Limited unauthorized access
Examples
- Repeatedly ignoring MFA requirements
- Sharing credentials despite security training
- Unauthorized access to internal confidential information
- Installing unapproved software that creates security risk
Typical Response
☐ Formal investigation
☐ Corrective action
☐ Targeted training
☐ Access review
☐ Manager involvement
☐ HR consultation where appropriate
☐ Risk treatment
18. High Severity
Typical characteristics:
- Restricted information involved
- Production access
- Privileged access
- Customer or personal data
- Significant control bypass
- Significant business impact
- Repeated serious non-compliance
- Evidence of reckless behavior
Examples
- Unauthorized access to production database
- Improper access to customer personal data
- Deliberate bypass of privileged-access controls
- Unauthorized transfer of confidential customer information
- Disabling security monitoring without authorization
Typical Response
☐ Formal investigation
☐ Immediate containment
☐ Security escalation
☐ Management notification
☐ HR review where personnel-related
☐ Legal/Privacy review where applicable
☐ Access suspension/revocation where justified
☐ Corrective action
☐ Risk acceptance or treatment
☐ Enhanced monitoring
19. Critical Severity
Typical characteristics:
- Severe impact
- Major customer/data exposure
- Significant production compromise
- Malicious activity
- Deliberate security-control circumvention
- Evidence destruction or concealment
- Major regulatory or contractual exposure
- Significant business disruption
Examples
- Deliberate theft of customer data
- Malicious use of privileged production access
- Intentional exfiltration of restricted information
- Deliberate destruction of security logs to conceal unauthorized activity
- Malicious modification of production systems
Typical Response
☐ Immediate executive escalation
☐ Security incident response
☐ Immediate containment
☐ Evidence preservation
☐ Legal involvement
☐ Privacy assessment
☐ Regulatory assessment
☐ Customer/contractual assessment
☐ HR investigation
☐ Independent investigation where appropriate
☐ Formal risk treatment
☐ Corrective action
20. Primary Classification Matrix
| Factor | Low | Medium | High | Critical |
|---|---|---|---|---|
| Information | Public/Internal | Confidential | Restricted/customer | Highly sensitive/restricted |
| Access | Standard | Sensitive | Privileged/production | Administrative/critical |
| Impact | Minimal | Moderate | Significant | Severe |
| Intent | Accidental | Negligent | Reckless | Intentional/Malicious |
| Control Bypass | None/minor | Limited | Significant | Deliberate |
| Customer Impact | None | Possible | Confirmed | Major |
| Privacy Impact | None | Limited | Significant | Major |
| Business Impact | Minimal | Moderate | High | Severe |
| Recurrence | First | Occasional | Repeated | Persistent/deliberate |
| Concealment | None | Possible | Evidence of concealment | Deliberate concealment |
| Response | Correct | Investigate | Escalate | Executive/legal response |
21. Severity Determination Rules
The highest-risk factor should be considered when determining overall severity.
For example:
Case A
- Confidential information
- Standard access
- Accidental
- No disclosure
- First occurrence
Likely classification: Low
Case B
- Customer information
- Unauthorized access
- Negligent
- No confirmed disclosure
Likely classification: Medium/High depending on scope and risk.
Case C
- Production database
- Privileged access
- Restricted customer information
- Deliberate unauthorized access
Likely classification: High/Critical
Case D
- Restricted information
- Deliberate exfiltration
- Evidence of concealment
Likely classification: Critical
22. Classification Decision Tree
Use the following sequence.
Step 1 — Is there evidence of a security requirement violation?
No → Close as No Violation / Security Concern.
Yes → Continue.
Step 2 — Is there an active security risk?
Yes → Contain immediately.
No → Continue investigation.
Step 3 — Is sensitive or restricted information involved?
Yes → Increase risk consideration.
Step 4 — Is privileged or production access involved?
Yes → Increase risk consideration.
Step 5 — Was the behavior repeated?
Yes → Increase severity consideration.
Step 6 — Was a security control deliberately bypassed?
Yes → Increase severity consideration.
Step 7 — Was the activity intentional or malicious?
Yes → High/Critical consideration.
Step 8 — Was there significant impact?
Yes → High/Critical consideration.
Step 9 — Was evidence concealed or destroyed?
Yes → Enhanced investigation and escalation.
23. Incident Classification
A security violation should also be assessed to determine whether it constitutes a security incident.
| Question | Yes/No |
|---|---|
| Was unauthorized access confirmed? | |
| Was confidential/restricted information exposed? | |
| Was customer information affected? | |
| Was personal data affected? | |
| Was a security control compromised? | |
| Was production affected? | |
| Was malicious activity suspected? | |
| Was availability affected? | |
| Was integrity affected? |
If applicable, activate the organization’s Information Security Incident Management Procedure in addition to the violation investigation process.
24. Privacy Classification
Where personal data is involved, determine:
☐ Personal data accessed
☐ Personal data copied
☐ Personal data modified
☐ Personal data disclosed
☐ Personal data transferred
☐ Personal data deleted
☐ Personal data exposure unknown
Privacy Severity
☐ Low
☐ Medium
☐ High
☐ Critical
Privacy classification should be performed in accordance with applicable privacy requirements and organizational procedures.
25. Customer Impact Classification
Where customer information or customer services are involved:
| Level | Description |
|---|---|
| C0 | No customer impact |
| C1 | Potential but unconfirmed impact |
| C2 | Limited confirmed impact |
| C3 | Significant customer impact |
| C4 | Major customer impact |
Consider:
- Number of customers
- Information sensitivity
- Service availability
- Contractual requirements
- Customer notification obligations
26. Regulatory/Contractual Classification
Assess whether the violation could trigger:
☐ Regulatory reporting
☐ Privacy notification
☐ Customer notification
☐ Contractual notification
☐ Security assurance requirement
☐ Audit requirement
☐ Legal review
☐ No known obligation
Do not determine legal obligations solely from this matrix. Refer to appropriate Legal, Privacy, Compliance, or responsible functions.
27. Response Classification
| Response Level | Typical Use |
|---|---|
| R1 | Awareness / correction |
| R2 | Formal investigation / corrective action |
| R3 | Security + management + HR/Legal review |
| R4 | Incident response + executive/legal escalation |
28. Recommended Response by Severity
| Severity | Investigation | HR | Legal/Privacy | Management | Incident Response |
|---|---|---|---|---|---|
| Low | Basic | As needed | As needed | Periodic | Usually no |
| Medium | Formal | As needed | As needed | Relevant owner | If applicable |
| High | Formal/enhanced | Usually | As applicable | Yes | Often |
| Critical | Independent/enhanced | Yes | Yes | Executive | Yes |
These are escalation guidelines and should be adapted to organizational requirements.
29. Disciplinary Considerations
Security severity does not automatically determine disciplinary action.
Consider separately:
- Intent
- Impact
- Training
- Awareness
- Role responsibility
- Previous history
- Repeated behavior
- Management instructions
- Control availability
- Contributing circumstances
- Applicable employment requirements
Principle
Security severity and disciplinary consequence are related but are not the same decision.
30. Violation Classification Record
| Field | Value |
|---|---|
| Investigation ID | |
| Violation ID | |
| Category | |
| Status | |
| Information Classification | |
| System Criticality | |
| Access Level | |
| Intent | |
| Actual Impact | |
| Potential Impact | |
| Recurrence | |
| Control Bypass | |
| Concealment | |
| Customer Impact | |
| Privacy Impact | |
| Regulatory Impact | |
| Overall Severity | |
| Response Level | |
| Incident Classification | |
| HR Referral | |
| Legal/Privacy Referral | |
| Investigator | |
| Date |
31. Classification Evidence
The classification should be supported by evidence such as:
☐ Access logs
☐ Authentication records
☐ Cloud logs
☐ Application logs
☐ Database logs
☐ Endpoint records
☐ Security alerts
☐ Emails
☐ Tickets
☐ Policies
☐ Training records
☐ Access approvals
☐ Interview records
☐ Previous findings
☐ Previous warnings
☐ Other evidence
32. Classification Review
A classification should be reviewed when:
☐ New evidence is identified
☐ Impact increases
☐ Customer impact is discovered
☐ Personal data is identified
☐ Malicious intent is suspected
☐ Additional systems are affected
☐ Additional personnel become involved
☐ Evidence of concealment is identified
☐ Regulatory implications become apparent
☐ Security incident status changes
33. Reclassification
If new evidence changes the severity:
Original Classification: __________
New Classification: __________
Reason for Change: __________
Evidence: __________
Reviewed By: __________
Date: __________
34. AWS SaaS Startup Example
Consider a SaaS startup using AWS.
Scenario
A developer uses another developer’s AWS credentials to access a production database.
Initial Facts
- System: AWS production
- Access: Privileged
- Information: Customer data
- Authorization: Not established
- Intent: Unknown
Initial Classification
Status: Under Investigation
Category: SV-02 Credential Misuse / SV-03 Privileged Access Misuse
Information: Restricted
Access: A5
Impact: Unknown
Intent: I-0 Unknown
Severity: High — pending investigation
Investigation Finds
The developer knowingly used another person’s credentials because their own account did not have the required access.
The developer accessed customer records but did not export or modify them.
Final Classification
- Category: Credential/Privileged Access Misuse
- Intent: Intentional
- Information: Restricted
- Access: Privileged/Production
- Actual Impact: Moderate
- Potential Impact: High
- Severity: High
- Incident Assessment: Security incident assessment required
- Corrective Action: Individual accounts, MFA, least privilege, privileged-access controls, monitoring and targeted training
The classification should be supported by the investigation evidence.
35. Startup-Friendly Classification Model
For a small startup, the matrix can be simplified to four questions:
1. What was accessed?
Public / Internal / Confidential / Restricted
2. What access was used?
Standard / Sensitive / Privileged / Production
3. What happened?
Accidental / Negligent / Reckless / Intentional / Malicious
4. What was the impact?
Low / Medium / High / Critical
Then determine:
Severity = Highest Relevant Risk Factor + Context
This prevents a startup from creating an unnecessarily complicated disciplinary framework while still maintaining a defensible process.
36. Common Mistakes
Avoid:
- Treating every policy violation as a critical violation.
- Treating every accidental mistake as misconduct.
- Automatically assigning severity based only on the person involved.
- Ignoring information classification.
- Ignoring privileged access.
- Ignoring potential impact.
- Ignoring repeated behavior.
- Ignoring evidence of deliberate control bypass.
- Assuming intent without evidence.
- Treating disciplinary severity as identical to security severity.
- Failing to reclassify when new evidence appears.
- Ignoring privacy or customer impact.
- Failing to document the rationale for classification.
37. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Security Violation Investigation Procedure | Establishes investigation process |
| Information Security Disciplinary Policy | Defines disciplinary principles |
| Information Security Disciplinary Process | Defines disciplinary workflow |
| Security Incident Management Policy | Defines incident governance |
| Incident Response Procedure | Defines incident response |
| Incident Investigation Procedure | Supports technical investigation |
| Security Incident Severity Matrix | Classifies security incidents |
| Security Findings Register | Records findings |
| Corrective Action Tracker | Tracks remediation |
| Evidence Preservation Procedure | Protects investigation evidence |
| Access Management Procedure | Controls access |
| Privileged Access Procedure | Controls privileged access |
| Security Awareness Policy | Defines awareness expectations |
38. ISO 27001 Connection
A Security Violation Classification Matrix supports a risk-based and consistent approach to handling information-security non-compliance and security events.
It can support areas relating to:
- Information-security incident management
- Access control
- Personnel security
- Logging and monitoring
- Information protection
- Risk management
- Corrective action
- Continual improvement
The Security Violation Classification Matrix is not itself a universally mandatory ISO 27001 document. The organization should define classification criteria appropriate to its ISMS scope, risk profile, business requirements, legal/regulatory requirements, customer commitments, and applicable controls.
39. Final Classification Checklist
☐ Violation identified
☐ Requirement identified
☐ Evidence reviewed
☐ Violation category assigned
☐ Information classification determined
☐ System criticality determined
☐ Access level determined
☐ Intent assessed
☐ Actual impact assessed
☐ Potential impact assessed
☐ Recurrence assessed
☐ Control bypass assessed
☐ Concealment assessed
☐ Customer impact assessed
☐ Privacy impact assessed
☐ Regulatory/contractual impact assessed
☐ Overall severity assigned
☐ Response level assigned
☐ Security incident assessment completed
☐ HR referral considered
☐ Legal/Privacy referral considered
☐ Classification rationale documented
☐ Classification approved where required
☐ Reclassification process established
40. Final Audit Trail
For every significant security violation, the organization should be able to demonstrate:
What requirement was violated?
What evidence supports the classification?
What information was affected?
What system was affected?
What level of access was involved?
Was the activity accidental, negligent, reckless, intentional, or malicious?
What was the actual impact?
What was the potential impact?
Was the violation repeated?
Were security controls bypassed?
Was there evidence of concealment?
Was customer or personal data affected?
What severity was assigned?
Why was that severity selected?
What response was required?
Were HR, Legal, Privacy, Compliance, or Management involved where appropriate?
Was the classification reviewed when new evidence became available?
Was the final decision recorded?
Final Principle
A security violation classification should be evidence-based, risk-based, and proportionate. The objective is not simply to label the person or event, but to consistently determine the security impact, intent, response, and corrective action required.
Classification Lifecycle:
Identify → Classify → Assess Intent → Assess Impact → Determine Severity → Escalate → Respond → Record → Review → Improve