Corrective Action Procedure

1. Purpose

This procedure defines the process for identifying, documenting, analyzing, and resolving nonconformities within Carriyo's Information Security Management System (ISMS). It ensures that corrective actions are systematically planned, implemented, and verified for effectiveness, driving continual improvement of the ISMS in accordance with ISO 27001:2022 Clause 10.

2. Scope

This procedure applies to all nonconformities identified through:

• Internal and external audits (CAR-ISMS-PRC-002)
• Management reviews (Clause 9.3)
• Security incident investigations
• Risk assessment findings
• Employee-reported concerns
• Monitoring and measurement activities
• Third-party assessments and penetration testing

3. Definitions

4. Procedure Steps

4.1 Step 1: Identification and Logging

1. Any employee, auditor, or stakeholder may identify a nonconformity
2. The nonconformity shall be reported to the Information Security Specialist via email or the incident management process
3. The Information Security Specialist logs the nonconformity in the Corrective Action Register with:
   • Unique CAR reference number (CAR-YYYY-NNN format)
   • Date identified
   • Source of identification (audit, incident, review, etc.)
   • Description of the nonconformity
   • Affected ISMS clause/control
   • Severity classification (Major or Minor)
   • Assigned owner for resolution

Severity Classification:

• Major: Nonconformity that affects the ability of the ISMS to achieve its intended outcomes, represents a significant security risk, or indicates a systemic failure
• Minor: Nonconformity that does not significantly impact the ISMS but represents an isolated deviation or area for improvement

4.2 Step 2: Immediate Containment

1. Assess whether immediate containment action is required to limit the impact
2. Document any containment actions taken
3. Notify relevant stakeholders if the nonconformity poses an active security risk

4.3 Step 3: Root Cause Analysis

The assigned owner shall conduct root cause analysis using one or more of the following methodologies:

5-Why Analysis:

1. State the nonconformity clearly
2. Ask "Why did this happen?" and document the answer
3. Repeat up to 5 times, each time asking "Why?" about the previous answer
4. Identify the root cause when further "Why?" questions yield no meaningful answer

Fishbone (Ishikawa) Diagram: Analyze potential causes across categories:

• People: Training gaps, awareness, competence, staffing
• Process: Procedure gaps, unclear responsibilities, workflow issues
• Technology: System failures, configuration errors, tool limitations
• Policy: Missing or outdated policies, unclear requirements
• Environment: External factors, regulatory changes, third-party dependencies

Document the root cause analysis findings in the CAR form.

4.4 Step 4: Corrective Action Planning

1. Define specific corrective action(s) to eliminate the root cause
2. Corrective actions must be proportionate to the severity of the nonconformity
3. Document in the CAR:
   • Planned corrective action(s) with clear deliverables
   • Responsible person(s)
   • Target completion date
   • Resources required
   • Expected evidence of completion

4.5 Step 5: Implementation

1. The assigned owner implements the corrective action(s) per the plan
2. Progress updates shall be provided at minimum:
   • Weekly for Major nonconformities
   • Bi-weekly for Minor nonconformities
3. Any changes to the plan (scope, timeline, approach) must be documented and approved by the Information Security Specialist
4. Update ISMS documentation as needed (policies, procedures, records)

4.6 Step 6: Effectiveness Verification

1. After implementation, allow an appropriate monitoring period (minimum 30 days)
2. Verify effectiveness by confirming:
   • The root cause has been eliminated
   • The nonconformity has not recurred
   • No new nonconformities have been introduced
   • Relevant metrics show improvement
3. Methods of verification may include:
   • Follow-up audit of the affected area
   • Review of monitoring data and logs
   • Interviews with relevant personnel
   • Testing of corrected controls

4.7 Step 7: Closure

1. If effectiveness is confirmed, the Information Security Specialist closes the CAR with:
   • Closure date
   • Evidence of effectiveness
   • Summary of lessons learned
2. If effectiveness is NOT confirmed:
   • Re-open the CAR
   • Conduct additional root cause analysis
   • Define revised corrective actions
   • Repeat steps 4-6
3. Closed CARs are reported in the next Management Review

5. Roles and Responsibilities

6. Timeframes

Timeframe extensions must be documented with justification and approved by the CISO.

7. Documentation Requirements

7.1 Corrective Action Request (CAR) Form Template

7.2 Corrective Action Register

A centralized register shall be maintained containing all open and closed CARs with status tracking. The register shall be reviewed:

• Weekly by the Information Security Specialist
• Monthly by CISO
• Quarterly during Management Reviews

8. Links to Related Processes

9. Records and Retention

All corrective action records shall be retained for a minimum of 3 years and shall be available for review during internal and external audits. Records include:

• Completed CAR forms
• Root cause analysis documentation
• Evidence of implementation
• Effectiveness verification results
• Corrective Action Register

10. Review and Approval

This procedure shall be reviewed annually or when significant changes occur to the ISMS. Changes require approval from the CISO.

Document History: