The change is ready, the engineers have a maintenance window, and all that is missing is sign-off for the outage. But who should sign? The original service owner moved to another department, their successor does not know they have inherited the role, and the team lead says it is not their call. The request travels from inbox to inbox, and the window expires.
The same thing happens with incidents, requests and audits. An auditor asks who approved a particular intervention, and the answer is dug out of old email threads. For operations staff, this means pointless waiting and the feeling of carrying responsibility nobody formally delegated. For service owners, it means the risk of learning about work on their service after the fact.
Why accountability gets blurred
Most organisations have a document that describes who is responsible for what. The trouble is that it lives apart from the tool where the work actually happens.
- A RACI matrix in a spreadsheet is not reflected in permissions. The person marked “accountable” often cannot approve anything in the system, and vice versa.
- Ownership is ambiguous. Sometimes the owner is recorded on the service, sometimes on the application, sometimes on the team, and each process picks a different one.
- There is no fallback approver. When an owner is absent or unassigned, the process stops.
- Permissions are too coarse. People either see everything or nothing, so roles are granted more broadly “just in case”.
A better way to think about ownership
Accountability is only useful when the system knows about it and enforces it. We suggest a few principles:
- One ownership rule for every process. Approving an outage, a request or a price list should follow the same logic.
- There is always a fallback decision-maker. If no owner is assigned, it is clear in advance who decides.
- Roles have scope. A permission applies to a specific customer, team or item, not to the whole system.
- RACI and permissions must match. Whoever is accountable for something needs the rights to act on it, and nobody else should have them.
- Every decision is traceable. Who, when and why.
How Eywo Stratum handles it
In Eywo Stratum, every service has an owner, and one rule determines who the owner is. The same rule applies across every process that needs consent: outages in changes, requests, patch agreements and price list proposals. All of these land in a single “Awaiting approval” queue. If a service has no owner, the change manager decides as the fallback approver, so nothing gets stuck. A rejection always comes with a reason.
Permissions are built on 14 roles with scope: everything, a customer, a team or a specific item. People get exactly the rights their role requires. Stratum also includes a RACI matrix with a consistency check against permissions. It flags anyone listed as accountable in the matrix who lacks the matching role in the system, and the reverse.
Every decision is written to an audit trail kept for five years. When an auditor asks who approved something, the answer takes moments, not days. During rollout, the operational readiness check verifies, among other things, that services have assigned owners and that roles are in place.
Conclusion
Clear ownership is not bureaucracy. It protects people. Engineers know whom to ask. Service owners know nothing happens to their service without their knowledge. And the organisation can show at any time who was responsible for what. All it takes is for accountability to live inside the system rather than in a spreadsheet next to it.
Service ownership, scoped roles, the RACI consistency check and the audit trail are all part of the Standard edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.