Page History

...

i. RCA and CAPA Requirement

All bugs or incidents escalated from support (L2 or Service Desk) must include

...

a Root Cause Analysis (RCA) before the ticket

...

can be closed.

...

This requirement applies regardless of severity (P1–P4),

...

though P1

...

and P2 issues demand deeper analysis and more thorough documentation.

...

The RCA should be documented as per this template, and a link should be added to the

...

dedicated field within the JIRA issue template for consistency and traceability.

Recommended RCA Format

To ensure clarity and uniformity, the following structure should be used when documenting RCAs

...

:

• Root Cause: What

exactly

• precisely caused the issue?

(e

• 
  E.g., unhandled null

case

• value,

config

• configuration drift, stale data, broken API

integration)

• contract

• Trigger: What condition or event

exposed

• surfaced the

root cause? (e

• issue?
  E.g., new data,

infra

• infrastructure change, user action

)

• Impact: What was the

visible impact (user/system)? Number of users affected? Duration?

• observable effect on users or systems?
  Include number of users affected and duration if available.

• Resolution / Fix: What action was

done to fix it

• taken to resolve the issue?

• Preventive Measures: What steps will be

done

• implemented to prevent

this from happening again? (tests,

• recurrence?
  E.g., additional test coverage, improved monitoring, refactoring,

docs, etc.)

• documentation updates

Roles and Responsibilities

• RCA Ownership:
  The RCA is owned by the developer who

...

• resolved the issue, with

...

• support from:

  • L2 Support

(

• • – for replication

/

• • details and logs

)

• • QA

(

• • – for verification and assessing regression

scope)

• • impact

Architect/

• • Tech Lead

(

• • / Architect – for complex or systemic issues

)

• RCA Review:
  The Tech Lead or QA Manager must review the RCA for

completeness and quality.

• :

  • Clarity and completeness

  • Depth of analysis

  • Inclusion of meaningful preventive actions

  If the RCA is

unclear

• insufficient, lacks

depth

• preventive measures, or

doesn't have preventive measures

• appears superficial, it must be revised before the ticket

closure

• is closed.

Continuous Improvement

Recurring

...

RCA patterns and systemic issues should be

...

flagged and discussed in:

• Sprint Retrospectives

• Monthly Quality Reviews

• Engineering Guild

/

• or Knowledge Sharing

sessions

RCA Do’s and Don’ts

✅ Do:

• Take time to analyze beyond surface symptoms

• Talk to Ops or QA to understand context

• Suggest system-level improvements if needed

❌ Don’t:

• Sessions

This helps drive organizational learning and long-term improvements in product quality and system reliability.

RCA Best Practices

Do:

• Dig beyond surface-level symptoms

• Collaborate with QA and Ops for context

• Recommend systemic improvements when applicable

Don’t:

• Assign blame to individuals or teams

• Write vague root causes like “code issue” or “logic bug”

• Skip documenting

• Blame individuals or teams

• Just write “fixed logic” or “code issue” as root cause

Skip

• preventive actions