In many IT departments, the weeks before an audit follow the same ritual. Several people put their regular work aside and assemble evidence. Who approved this change? Why did this user have administrator rights? When did the firewall configuration change, and who changed it? The answers exist, but they are scattered across emails, chats, exports from different tools and the memories of people, some of whom have since left the company.
At the same time, the pressure to provide evidence keeps growing. Cybersecurity regulation, such as NIS2 and the national legislation that implements it, generally puts weight on risk management, management accountability and the ability to show that security measures actually work. Specific obligations differ by type of organization and are best assessed with legal or compliance specialists. The common thread, though, is clear: doing things right is not enough. You have to be able to prove it.
Why assembling evidence after the fact fails
The problem is rarely that an organization has no processes. The problem is that those processes do not leave a trail on their own.
- Approvals happen outside the system. Consent to an outage arrives by email, the change is carried out elsewhere, and the link between them exists only in the change manager’s head.
- History gets overwritten. The tool shows the current state, but not what it looked like before.
- Automated actions are invisible. Scheduled jobs change data, but nobody knows exactly when or what they did.
- Responsibilities live on paper. A RACI matrix sits in a document, and nobody checks whether it matches actual permissions.
The result is an audit run as a project, instead of an audit as a routine look at the records.
How to approach provability
Real audit readiness is a by-product of everyday work. If every action happens in a system that records it, the evidence exists at the moment things happen. A few principles:
- record not only “who and when” but also “what exactly changed”, meaning the state before and after,
- audit what machines do, not just what people do,
- keep records for long enough,
- describe responsibilities in a way that can be compared with actual permissions.
How Eywo Stratum handles it
Eywo Stratum keeps an audit trail of all actions, retained for five years. For configuration changes, it records the state before and after, so you can see not only that something changed but exactly what. Scheduler actions, the automated jobs that run without human input, are audited as well.
CMDB items have their own version history. For every change you can see who made it, when, what changed and where it came from: the discovery API, an import, a manual edit or synchronization with a primary CMDB.
Approvals happen inside the system. Outages in changes, requests and other items that need a decision come together in a single “For approval” queue. One rule defines who the owner is, and a rejection always comes with a reason. The record of who agreed to what is created right alongside the change.
Responsibilities are described in a RACI matrix, and Eywo Stratum checks that it is consistent with permissions. If someone is listed as accountable but has no role that would let them approve or carry out the task, it shows. Roles are scoped (everything, customer, team, item), so it is clear not only what someone may do but also over what.
Conclusion
An audit should not be a project. When the audit trail is created automatically, approvals live in the system and responsibilities are tied to permissions, the answer to an auditor’s question is a few clicks away. The team keeps working, and management can be confident that accountability can be proven.
The audit trail, CMDB history and RACI matrix are included in the Standard edition.
Eywo Stratum Standard
For organisations that want a reliable CMDB and managed ITSM processes.