The feature was merged on a Tuesday and shipped four weeks later. Nothing was fixed in between. The delay was one reviewer's diary, one missing document reference, and a change advisory board that meets on alternate Thursdays.
Compliance sign-off is the formal confirmation, by someone outside the delivery team, that a change meets the obligations your firm is held to, and that they will put their name to it. It is not a review, not an opinion, and not the conversation you had by the coffee machine. It is a dated dependency with a queue in front of it, and the thing it rejects is almost never your feature.
What compliance sign-off actually is, and who gives it
Compliance sign-off is a named individual accepting accountability that a change meets a stated obligation, recorded in a way that survives an audit. It is given by someone in the second line — compliance, risk, legal or a control owner — who does not report into delivery, and who is judged on what they approved rather than on what shipped.
That last clause explains most of the behaviour you find frustrating. Your incentives and the reviewer's are not opposed, but nor are they aligned: nothing good happens to them when your release goes out on time, and something bad happens if it goes out wrong. Asking them to move faster is asking them to carry more risk for no return. Every technique that works here works by reducing what the reviewer has to take on trust, not by applying pressure.
The cast has a shape worth learning, and it is the structure every regulated firm puts around delivery. Business and delivery teams own and manage risk directly; a second line sets policy and challenges independently; internal audit gives assurance to the board. The Institute of Internal Auditors (IIA) issued a new Statement of Position on the Three Lines Model in July 2026, replacing the 2020 position paper and leaning harder on accountability. If your internal policy still describes three lines of defence in the older framing, expect it rewritten around you during the year.
Why sign-off lands after the sprint closes
Sign-off lands late because the evidence a reviewer needs cannot exist until the build is largely finished, and because reviewers are a shared, fixed resource across every delivery team in the firm. Your sprint is two weeks. Their queue is not organised in sprints at all, and nothing about your ceremony calendar is visible to them.
Three mechanics do the damage, and they compound. Sequencing: a reviewer needs screenshots, a data flow, a retention decision and a test result, none of which are real until the feature is. Capacity: the same person covers four squads, and reviews arrive in bursts near everyone's release dates. Diary structure is the cruellest of the three: approvals route through a committee with a fortnightly slot, so missing it by a day costs a fortnight.
Then there is the reviewer who was not at kickoff. They read the ticket for the first time at the point of approval and re-open a decision the team settled six weeks ago, because from where they sit it was never settled. This is not obstruction. It is what happens when you involve someone at the end of a process whose reasoning happened at the start, and it is the most avoidable delay in the list.
[ASHISH: add a real example of a release delayed by sign-off — what the reviewer asked for, how long it took to produce, and whether the feature itself changed at all.]
What gets rejected is the evidence, not the feature
Approvals are rarely refused on the substance of what you built. They stall on missing artefacts: no record of who decided a retention period, no reference number for an assessment that was completed but never linked, no written confirmation from the team that owns the control your feature depends on. The product is fine. The file is not.
Look at the shape of a rejection. Nobody says the payment limit is wrong; they ask which policy sets it, and whether the person who owns that policy has seen the screen. Nobody says the audit log is inadequate; they ask what it retains, for how long, and who authorised the answer. You are not being asked to justify a decision, you are being asked to prove one was taken by someone entitled to take it.
The practical consequence is that the evidence is a deliverable of the sprint, not paperwork that follows it. Reason codes, consent flags, an exportable log, a screen that shows the disclosure — each of those is a story with acceptance criteria, and it is worth writing them into the acceptance criteria alongside the functional behaviour rather than leaving them to the last refinement session. Features built on a model attract a heavier version of this, because the reviewer wants to see the evaluation evidence tied to a specific version rather than a general claim about performance.
The forms approval takes, and how each one fails
Not every yes is the same yes, and the difference matters on the day something goes wrong. Six forms recur in regulated delivery, each with its own failure mode — usually a mismatch between how binding the team believed it was and how binding it proves to be.
| Form of approval | What it gives you | How it fails |
|---|---|---|
| Verbal agreement in a meeting | Speed, and an early read on whether the approach is viable at all | Binds nobody. The reviewer remembers agreeing to the principle; you remember agreeing to the design. Neither is written down, and the disagreement surfaces at the point you needed the approval |
| Email or chat confirmation | A record, and usually enough to keep a build moving | Rarely states what was approved with enough precision to survive a change. Sits in a mailbox rather than the change record, so an auditor cannot find it and neither can your successor |
| Conditional approval | You can ship now against a list of commitments | The conditions carry dates set by the reviewer, not by your roadmap, and they compete with committed work rather than joining it. Teams celebrate the yes and forget the list until it is overdue |
| Formal sign-off against a version | The strongest position: a named approver, a dated record, a defined scope | It is version-specific. Approval granted on build 4.2.1 does not cover 4.2.3, and nobody notices until an auditor compares the change record with what is running |
| Standing or delegated approval | Routine changes ship without a queue, which is the outcome you actually want | The delegation has boundaries nobody re-reads, so a change creeps outside its scope by degrees. The first time anyone checks is after an incident |
| Emergency change, approved afterwards | A legitimate route for a production incident at 22:00 | The retrospective approval never gets completed, because the incident is over and the urgency has gone. This is a documented obligation in the European Union, and an open finding waiting to be written |
The fourth row is the quiet one. A sign-off is a statement about an artefact, not a blessing on a feature, and every rebuild after it changes what was approved. Agree with your reviewer in advance what constitutes a material change for this specific piece of work — configuration, copy, thresholds, model version — and you convert an unbounded obligation into a short list you can watch.
What the rules actually require of a change
Change approval is not only internal policy. For European Union financial entities the Digital Operational Resilience Act (DORA) sets requirements through its technical standards, and they describe the approval process your firm has to operate rather than leaving it to local custom. Reading them tells you which of your reviewer's demands are negotiable and which are not.
Commission Delegated Regulation (EU) 2024/1774, which supplements DORA, sets out ICT change management at Article 17. Four requirements shape delivery directly. Approval functions must be independent of those requesting and implementing the change, which is why your tech lead cannot approve their own work however senior they are. Changes must be tested and finalised in a controlled manner. The record must state purpose, scope, timeline and expected outcomes. And fall-back procedures must name who may abort a change or recover from one that failed.
That fourth requirement is worth reading twice, because most teams treat rollback as an engineering detail. Here it is part of what gets approved. If you cannot describe how the change is reversed and who is entitled to reverse it, you have not finished preparing for sign-off, whatever the feature does. The regulation is equally explicit that emergency changes need safeguards and must be documented, re-evaluated, assessed and approved after the event — the hotfix is legitimate, the silence afterwards is not.
Where a change is driven by a regulatory deadline rather than your own roadmap, the approval work is part of the obligation and belongs on the same part of the backlog as the dated change itself, in sprints with numbers on them. Treating the build as the commitment and the approval as an afterthought is how firms miss dates they had eighteen months of warning about.
How to get sign-off inside the sprint
Getting compliance sign-off inside the sprint means moving the reviewer's questions to the front and producing their evidence as you build. The work is identical either way; what changes is whether it happens during delivery or in a queue afterwards. Run it in this order, starting at refinement rather than at code freeze.
- Ask, before the first story is estimated, who the named approver is and what they will need. Not the team — the person. If nobody can name one, that is your first finding, not theirs.
- Get the evidence list in writing at kickoff and turn each item into a story with acceptance criteria. A reviewer who has told you what they want in week one cannot invent a new requirement in week six without it being visible.
- Put the reviewer in one refinement session, once. Attendance is cheap and it removes the entire class of delay caused by someone meeting the decision for the first time at the end.
- Agree what counts as a material change for this work, and write it into the change record. This defines when you must go back and, more usefully, when you need not.
- Write the fall-back plan as a specified artefact — how the change is reversed, by whom, and what customers see while it is being reversed — and submit it with everything else.
- Book the committee slot before you need it. Approvals routed through a fortnightly forum have a calendar, and missing it by a day costs a fortnight.
- Track conditional approvals as dated work with owners the moment you accept them, in the same place as your other commitments. A condition you accepted and did not schedule is a finding you agreed to in advance.
Step one is the whole procedure in miniature: a named approver in week one costs an email, and an unnamed approver in week six costs a release. The predictable failure here is teams doing steps two to seven well while skipping step one, then discovering that the person who finally reviews the work has a different view from the person who briefed them, and none of the evidence was gathered for the standard being applied.
[ASHISH: add a real example of a control or obligation that was identified during refinement rather than at the end, and what it changed about the design.]
When the answer comes back as a refusal, treat it as a defect with a root cause rather than a verdict, and ask three questions in order: which specific obligation is not met, what evidence would satisfy it, and whether that evidence is producible at all. The third question separates a fortnight's work from a design change. Escalating instead buys an approval from someone who did not examine the work, at the price of a harder look at everything you submit next quarter.
Terms of art worth agreeing once
Six terms carry most of the confusion, and two of them are used interchangeably by people who mean quite different things. Agree them with your second line before your first submission, because an argument about approval that is really an argument about the word "owner" costs a fortnight and makes your team look unprepared.
- Compliance sign-off is a named individual's recorded acceptance that a change meets a stated obligation, given by someone outside the delivery team.
- Second line is the set of functions — compliance, risk, legal — that set policy and independently challenge the first line, without owning delivery of the work themselves.
- Control owner is the person accountable for a specific control operating as designed, who is often not the same person as the approver of your change.
- Conditional approval is permission to proceed subject to named commitments with dates, each of which is real work that must be scheduled.
- Material change is an alteration significant enough to invalidate an existing approval, defined per piece of work rather than globally.
- Emergency change is a change deployed outside the standard approval path to address an urgent issue, which must still be documented, assessed and approved afterwards.
Write down the refusals as carefully as the approvals, because a documented no with its reasoning stops the same design being proposed again in two years by someone who was not there. Then one gap remains: the evidence you cannot produce yourself because it belongs to a supplier. A reviewer will ask how a third-party component behaves, and the vendor's answer is a commercial document rather than a test result — which turns the build-or-buy decision in fintech into a question about who can evidence a control, not who can deliver faster.
Frequently asked questions
What is compliance sign-off?
Compliance sign-off is a formal, recorded confirmation from a named person outside the delivery team that a change meets the obligations the organisation is held to. It differs from a review or an opinion because the approver accepts accountability for the decision, and the record is expected to stand up to internal audit or a regulator months later.
Who signs off a product change in a bank?
Usually a named individual in a second-line function — compliance, risk or legal — or the owner of the specific control the change touches. The approver must be independent of the people requesting and implementing the change. Identify the individual rather than the department at the start, because departments do not sign anything and diaries belong to people.
How long does compliance approval take?
It depends on the reviewer's queue and whether approval routes through a committee, and both sit outside your control. Plan it as a dated dependency with a lead time rather than a task inside a sprint. Ask two things early: the current turnaround, and the date of the next approval forum, since missing a fortnightly slot costs a fortnight.
What is the difference between the first line and second line of defence?
The first line is the business and delivery teams who own and manage risk in the course of doing the work. The second line sets policy, provides expertise and challenges the first line independently, without owning delivery. Internal audit forms a third line providing assurance to the board. The Institute of Internal Auditors refreshed this model in 2026.
Can you ship a feature without sign-off?
Only through a defined route, such as an emergency change for a production incident, and that route carries obligations of its own — safeguards at the time, then documentation, reassessment and approval afterwards. Shipping outside an approved path because a reviewer was slow is a control breach, and it is recorded as one regardless of whether the change was harmless.
What does DORA require for change approval?
Commission Delegated Regulation (EU) 2024/1774, supplementing the Digital Operational Resilience Act, requires an ICT change management procedure. Approval functions must be independent of those requesting and implementing changes; changes must be tested and finalised in a controlled manner; records must state purpose, scope, timeline and expected outcomes; and fall-back procedures with named responsibilities must exist.