Lesson 5 of 6
Open defects and risk acceptance
10 min
Very few SAP releases go live with zero open defects. That is acceptable, as long as every open defect is known, assessed and owned. Risk acceptance is the formal way for the business to say: we know this is not fixed, we understand what it means, we have a way to work around it, and here is when it will be fixed.
Must-fix versus can-defer
Severity alone is not enough. A high-severity defect that only affects one rare scenario may be deferrable with a workaround; a medium defect that hits every billing document may not. Ask both questions: how bad, and how often.
What a risk acceptance contains
| Field | Contoso example |
|---|---|
| Defect ID and description | DEF-0412: delivery note prints without the customer PO number for orders from plant 1720 |
| Business impact | Great Lakes Fleet Services receiving docks may query deliveries; no financial impact |
| Likelihood | All Chicago deliveries, about 40 per week |
| Workaround | Shipping team writes the PO number on the note; Maria briefs the team |
| Workaround owner | Chicago shipping supervisor |
| Fix owner and due date | Output team; fix in the first post-go-live release, by 30 days after go-live |
| Accepted by | Dan, process owner, with date |
| Review | Checked weekly in hypercare until closed |
Contents of a risk acceptance.
Who can accept
Only someone who owns the business consequence can accept the risk. For a process defect that is the process owner. For a defect with financial reporting impact, finance leadership and often internal control should agree. For a defect touching legal or tax requirements, the relevant function must sign too. The test lead and PMO can recommend, but they cannot accept business risk on the business's behalf.
- TriageTest lead confirms severity, impact and likelihood
- OptionsFix before go-live, or defer with workaround
- Workaround testedKey user proves the workaround works
- AcceptProcess owner (plus finance or control if relevant) signs with fix date
- TrackReviewed in hypercare until fixed and verified
Risk acceptance is also a communication tool. The people who will run the workaround, such as the Chicago shipping team in the example, need to hear about it before go-live, not discover it on the first morning. Include accepted risks and their workarounds in end-user training and in the hypercare briefing, and give the service desk a short note so they recognize the issue when users report it.
Avoiding the common traps
- Do not downgrade severity to make a gate pass. Accept the risk at its real severity.
- Do not accept defects without a fix date. "Later" is not a date.
- Do not accept a pile of individually small defects without asking what they do together in one process.
- Do not let accepted risks disappear after go-live. They belong on the hypercare agenda.
What would you do?
At the UAT exit gate, Contoso has one open high-severity defect: the credit check does not block orders for a small customer group that places about two orders a month. A manual credit review is possible. What should Dan do?
- Classify open defects by impact and likelihood, not severity alone.
- A risk acceptance names the impact, workaround, owners, fix date and who accepted.
- Only the owner of the business consequence can accept the risk.
- Never downgrade severity to pass a gate; track accepted risks through hypercare.
Check your understanding · not graded
Lesson check
1. Which two questions classify an open defect for deferral?
2. Which item must a risk acceptance include?
3. Who can accept business risk for a process defect?
4. What should happen to accepted risks after go-live?