Companies are aware of their obligations: stricter requirements for access controls, traceability and risk management under NIS2, DORA, ISO 27001 and the BSI IT-Grundschutz have long been on the corporate agenda. Yet practical implementation often slips down the priority list. Too many unanswered questions stand in the way of stronger protection. Modern PAM functions can help translate abstract obligations into concrete controls.

NIS2, DORA, ISO 27001 and the BSI IT-Grundschutz usually do not explicitly name Privileged Access Management, or PAM, as a mandatory measure. Instead, they remain more general and call for controlled access to critical systems, limited risks, traceable assignment of permissions and well-documented security measures. This is exactly where PAM comes in — as explored in more detail in our blog post “Regulatory Pressure: Why Access Controls Matter for NIS2, DORA and Beyond.”

However, the challenge does not begin with tool selection. After all, laws and guidelines do not define tool requirements. They demand fundamental security principles, including in the area of access control. What is often missing is a solid understanding of how to move from theory to practice:

• What does “controlling access” mean in concrete terms?
• Which types of access qualify as privileged access and require special protection?
• Where do risks currently exist? How can they be limited?
• How can permissions be assigned in a traceable manner?
• What evidence of security measures do auditors expect to see?
• How can the effectiveness of these measures be reviewed regularly?

This is where uncertainty usually arises. The IT department understands the technology. Compliance has the requirements in view. Business units want as little friction as possible in their day-to-day work. Yet companies often fail to connect these departments and their respective needs. PAM functions can help here. They build a bridge between regulatory requirements, technical implementation, organizational processes and auditable evidence. And still, many organizations ask themselves: Where can we realistically start without triggering an excessive, costly transformation project?

It is important to make one thing clear upfront: PAM is not a single solution for meeting every regulatory requirement. But PAM can translate recurring core principles from the frameworks mentioned above into concrete measures.

Audit question: Which privileged accounts exist, and who is responsible for them?

Companies cannot protect what they do not know exists. That is why they should start by taking a closer look and identifying privileged accounts. In addition to classic admin accounts, these include service accounts, technical users, cloud roles, API keys, emergency accounts and third-party provider access.

Anyone who wants to start from the beginning can find answers in our blog post “What Is Privileged Access Management? Fundamentals and Best Practices.”

PAM first and foremost supports the inventory of privileged accounts. Modern PAM solutions also make it easier and faster to identify critical systems and access rights. Once there is clarity about which privileged accounts exist, those responsible can begin prioritizing them according to risk and criticality. The transparency gained also makes it easier to assign appropriate owners.

Audit question: Why does a person or account have exactly these rights — and when was the assignment last reviewed?

Audit question: Why does a person or account have exactly these rights — and when was the assignment last reviewed?

Audit question: How is it ensured that privileged access is protected by more than just a username and password?

Security means more than entering a username and password. This applies to accounts in general, but even more so to privileged accounts that provide access to highly sensitive data and corporate information. Access to production systems, cloud environments, databases, security tools and administration interfaces must be assessed as particularly critical.

PAM solutions should therefore offer a number of security safeguards, especially multi-factor authentication for privileged access. Human and non-human identities must authenticate themselves using at least two independent factors. In addition, the following three requirements should apply: access may only take place from defined environments or within defined time windows; additional approvals are required for particularly critical systems; and context-based access controls apply to every access attempt.

Audit question: Who approved access, on what basis and for what period of time?

Critical rights are often granted by email, ticket or informal agreement. This makes it difficult later on to trace who approved which access and why. Yet this is exactly the kind of evidence many laws and guidelines require in order to make measures auditable.

Manual documentation scattered across multiple systems is still common today. Digital approval workflows and automatic documentation of decisions can provide significant relief. From an organizational perspective, companies can support the functions of modern PAM by defining processes for granting, changing and revoking rights, establishing clear roles for requesters, approvers and system owners, and introducing a four-eyes principle for critical access.

Admittedly, what has been described above may still sound rather theoretical to many decision-makers. They often classify PAM implementation as a mammoth task, both technically and organizationally. The ambition to fully control all privileged access immediately can block the starting point. But doing everything at once — preferably yesterday — should not be the goal. What matters more is a risk-based approach. Organizations should start where they assess risks as high and the expected impact as significant. Various PAM projects have shown us that the following five steps are effective.

Step 1: Prioritize Critical Systems

It is certainly forward-looking to examine the entire IT landscape. But companies reach their goals faster when they take small steps. This means they should first focus on systems that are particularly critical. The central question is: How serious would the consequences be if such a system were compromised?

Initially, the focus should be on production systems, cloud administration access, databases, security tools, production and OT-related systems, as well as external service provider connections and their privileged access rights.

Step 2: Make Privileged Accounts Visible

The second step is about creating transparency: Which privileged accounts exist? Who owns them? Which systems do they access? Which rights are permanently active? And which access rights are still needed? Only once this overview exists can companies assess risks, assign responsibilities and decide which accounts to include in their PAM strategy first.

Ideally, modern PAM tools take into account not only classic admin accounts, but also service accounts, technical users, cloud roles, API keys, emergency accounts and access granted to external service providers.

Step 3: Implement Quick Wins

The first steps have already shown the way forward: teams now know which systems are particularly critical and which privileged accounts play a role there. From this, initial measures can be derived that have a quick impact — without having to overhaul the entire IT landscape.

Key quick wins include reducing permanent admin rights, introducing multi-factor authentication for privileged access, and controlling or gradually replacing shared accounts. Those responsible should also limit external service provider access in time, clearly regulate emergency accounts and activate initial logging.

Step 4: Select and Test a Pilot Area

Now it is time for implementation — and for testing, testing and more testing. To do this, organizations should not look at the big picture, but ideally focus on a suitable pilot area. This could be an admin group, a specific critical system, third-party provider access, cloud admin access or database administration.

At this stage, IT checks whether processes run smoothly, whether the necessary evidence is generated and documented, and whether the technical integration has been successful. It is also worth asking employees whether they can work well with the new processes and authentication methods. After all, employee acceptance is just as important as technical functionality.

Step 5: Scale Further

Once the pilot project has been completed successfully, additional systems can be connected. The advantage: employees are gradually introduced to the new processes, and the IT department can use the experience gained from the pilot before rolling out PAM more broadly.

At the same time, recurring processes can be established, such as regular access reviews, recertifications and reports for compliance and management. This allows PAM to grow in a controlled way into the existing IT and governance landscape.

Regulatory requirements often seem abstract. That is why many companies hesitate to take the first step. Or they rush ahead without focusing on what matters most. When decision-makers want to address access control, they should therefore pause briefly and return to a few core questions: Who is allowed to do what? Why? For how long? Who approved it? How is it documented? PAM helps answer these questions in a structured way — step by step. This turns regulatory obligation into concrete security practice.