Imagine an incident has just occurred. The supervisory authority is asking questions: Who had access to the data, and when? Which account was used? When was the password last changed, and by whom?
Most organizations answer: we don’t know. Not because they are hiding something – they simply never recorded it.
This is a scenario that is becoming increasingly costly in the context of growing regulatory requirements (GDPR, NIS2) and tightened powers of supervisory bodies. It is not about a formal lack of documentation, but about the gap between the declared level of security and the ability to demonstrate it at the very moment it is actually verified.
Accountability in cybersecurity is not solely a legal requirement. It is an operational issue – and its source is control. Where there is no control, accountability is impossible – regardless of the number of security policies sitting in a drawer.
Regulations require hard evidence
GDPR: the controller must demonstrate, not just declare
Article 5(2) of the GDPR formulates the principle of accountability directly: the controller shall be responsible for, and be able to demonstrate compliance with, the regulations. Not declare it, or describe it in a policy. Demonstrate it, which means presenting evidence.
In practice, this means that simply implementing security measures is insufficient. As an analysis of the accountability principle indicates, accountability consists of two duties: implementing measures that guarantee compliance with the regulations, and preparing documentation that allows demonstrating what measures have been taken. One without the other does not fulfill the requirement.
Importantly, the GDPR does not dictate a single, mandatory method for implementing this principle. It provides flexibility, but this works both ways: the organization itself must choose adequate measures and, in the event of an audit, justify their choice and effectiveness.
The gap between security policy and reality
The security policy exists, but the access history is missing
Most organizations possess a “paper” security policy. Far fewer possess something that holds real value at the moment of an incident: an operational history. A record of who, when, and to what had access, when passwords were changed, to whom permissions were granted, and when they were revoked.
A security policy describes how things should be. An operational history documents how things were. During an audit, the supervisory authority verifies the latter. A document describing the rules of a password policy will not replace a log confirming that the standard was maintained.
Shared accounts and passwords passed via email make accountability impossible
The documentation of permissions and access plays an important evidentiary role. In the event of a breach, it allows for quickly establishing who had access to the data at a given time. This is a prerequisite for an effective investigation and incident response.
Meanwhile, practices such as shared accounts, passwords passed via email or communicators, and informally managed access hinder this capability. When several people log into the same account using the same password, establishing who performed a specific operation at a specific moment is impossible.
“Who logged in?” – an unanswered question
A security incident triggers a sequence of questions that an organization must be able to answer quickly and precisely: which account was used? Were the login credentials unique to a specific person? When was the password for this account last changed? Was access to the system restricted to authorized individuals? Was access revoked after the employee left?
Each of these questions requires operational data – not declarations. An organization that cannot answer them not only has a problem demonstrating accountability but also faces issues with mitigating the consequences of the incident, because it does not know its actual scope.
Control over access as a foundation, not a formal requirement
Control over access and passwords is, above all, an element of operational security, and it is from this security that its regulatory value is derived, not the other way around. An organization that knows who has access to what can react quickly to an incident, limit its scope, and document the actions taken. An organization that lacks this knowledge reacts slower, reconstructs events from the memories of participants, and is unable to reliably demonstrate what actually happened.
Centralized identity management
A centralized repository of login credentials, where every access is assigned to a specific user, every share is recorded, and every revocation of permissions is immediate and documented, creates an operational history that cannot be recreated in any other way.
In the context of accountability, the key point is that this history is created as a natural byproduct of proper access management – not as an additional documentation effort. An organization that centrally manages access with a password manager can point out at the moment of an audit: when the account was created, who had access to it, when access was modified, and when the password was changed and by whom.
Find out how a password manager fits into the NIS2 requirements.
A password manager in the organization
The perc.pass password manager is a tool that turns paper declarations into operational evidence. The documentation of actions taken on access levels creates itself as a natural result of daily work.
Control over the “shared account”
When a team logs into a shared inbox ([email protected]) using traditional methods, the password circulates unsupervised. You never know who actually knows it (including former employees). In perc.pass, you lock this password in a central safe and precisely assign specific users to it. In the event of an incident, the administrator does not have to guess – they immediately generate a closed, named list of individuals who possessed the credentials at the given time, and see the full history of granting and revoking those permissions.
Automatic audit log
When questions are asked, you don’t have to guess. Every creation, edit, or sharing of a password in perc.pass leaves a permanent footprint. In the event of an audit, you generate a report that becomes hard evidence demonstrating compliance with procedures.
Support in incident reporting
The obligation to report a significant incident (a NIS2 requirement) requires immediate knowledge of its scale. Thanks to a centralized database, an administrator can check within a few minutes which systems the compromised user had access to and block them immediately. This shortens the analysis time from days to minutes.
Readiness for audits (On-Premise Model)
Perc.pass offers deployment directly within the client’s own infrastructure (On-Premise / Appliance). This means that not only the passwords themselves but the entire strategic operational history never leaves the organization’s servers.
Discover perc.pass in the on-premise version!
If you want to check what central access management looks like in practice – test perc.pass during a free trial period. The history of access operations begins to form from the very first day of use.