Lesson 6 of 6
Who signs what
10 min
Listen to this lesson
A sign-off is only meaningful if the right person gives it. The person must own the thing being accepted, have the authority to accept the risk, and have seen the evidence. On SAP programs, three kinds of acceptance are commonly separated: functional (do the business processes work as designed), technical (is the platform, security, integration and operation sound) and business acceptance (is the business ready to run on it).
| Functional | Technical | Business acceptance | |
|---|---|---|---|
| Question answered | Do the processes work as designed? | Is the platform sound and operable? | Is the business ready to run on it? |
| Who signs | Process owners | Platform, security, integration and operations leads | Sponsor and steering committee |
| Main evidence | Test results for their processes | Performance, roles, interfaces, monitoring and jobs | All sign-offs, gate results, training and cutover readiness |
| Contoso example | Dan signs finance | Security lead accepts roles and authorizations | Sponsor makes the go/no-go call |
Functional sign-off
Functional sign-off belongs to process owners: the business leaders accountable for order to cash, procure to pay, finance and so on. At Contoso, Dan signs finance; the sales process owner signs order to cash with Maria's results as the evidence. Functional leads from the integrator confirm their solution was built and tested to design, but they cannot accept on the business's behalf.
Technical sign-off
Technical sign-off belongs to the platform and technology owners: the Basis or platform lead for system readiness and performance, the security lead for roles and authorizations, the integration lead for interfaces, and the operations or support lead for monitoring, jobs and support readiness. On RISE with SAP, some technical operations are provided by SAP, but the customer still needs its own technical owners to accept what affects them.
Business acceptance and go-live
Business acceptance belongs to the sponsor and senior business leadership, often through the steering committee. It goes beyond testing: users trained, data migrated and reconciled, cutover rehearsed, support model in place, and the business willing to change how it works on the go-live date. The go/no-go decision is theirs, based on all functional and technical sign-offs, the quality gate results and cutover readiness from Luis.
The test lead's role
The test lead does not accept business risk. The test lead attests to the evidence: that testing was performed as planned, results are recorded accurately, defects and risks are reported honestly, and the test summary reflects reality. Priya's signature says "this is what we know". Dan's signature says "knowing that, I accept it". Mixing the two weakens both.
- TestTesters and key users such as Maria execute and record results
- AttestPriya confirms the evidence is complete and honest: this is what we know
- AcceptDan accepts the residual risk for finance: knowing that, I accept it
- DecideSponsor and steering committee make the go/no-go call on all sign-offs
| Activity | Test lead (Priya) | Process owner (Dan) | Key user (Maria) | Technical leads | PMO lead (Grace) | Sponsor |
|---|---|---|---|---|---|---|
| Agree exit criteria | R | A | C | C | C | I |
| Execute UAT | C | A | R | I | I | I |
| Test summary report | A/R | C | C | C | I | I |
| Functional sign-off | C | A/R | C | I | I | I |
| Technical sign-off | C | I | I | A/R | I | I |
| Quality gate | C | C | I | C | R | A |
| Go/no-go decision | C | C | I | C | R | A |
Independence and delegation
Two principles keep sign-offs honest. First, independence: people should not accept their own work. The integrator's functional lead should not sign business acceptance; the developer should not close their own defect without a tester's retest. Second, explicit delegation: if Dan cannot attend, he can delegate signing to a named deputy in writing, with the same access to evidence. Sign-offs by whoever happens to be in the meeting are not sign-offs.
- Does this person own what is being accepted?Yes → next · No → find the accountable owner
- Did they build or deliver it?No → next · Yes → they cannot accept their own work
- Have they seen the evidence?Yes → next · No → share the test summary first
- Signing for someone else?No → they may sign · Yes → only with written delegation as a named deputy
Write the sign-off matrix into the test strategy or governance plan at the start of the program, and review it when people change roles. At Contoso, Grace's PMO keeps one table listing every planned sign-off, its accountable person, their named deputy and where the signed record will be stored. When the go/no-go meeting arrives, nobody has to ask who should have signed what.
What would you do?
At Contoso's go/no-go meeting, the integrator's project manager offers to sign UAT for finance because Dan is on vacation and "we know the results are fine". What is the right response?
- Functional sign-off: process owners. Technical sign-off: platform, security, integration and operations leads. Business acceptance and go-live: sponsor and steering committee.
- The test lead attests to the evidence; owners accept the risk.
- Use a RACI so each sign-off has one accountable person.
- Nobody accepts their own work; delegation must be explicit and informed.
Check your understanding · not graded
Lesson check
1. Who should give functional sign-off for finance processes at Contoso?
2. What does the test lead's signature attest to?
3. Who typically gives technical sign-off for authorizations?
4. Who is usually accountable for the go/no-go decision?
5. Which principle forbids the integrator's functional lead from signing business acceptance?