If you assess organizations against NIS2 obligations, you've probably noticed the same pattern. The policy is approved, the board minutes say the right things, and then you ask for proof that access controls actually work. The room goes quiet.
NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation, and complete cybersecurity training. Members can be held liable for infringements, subject to national law. Access control sits in the Article 21 measures, alongside asset management and multi-factor authentication where appropriate. Roughly 160,000 entities fall in scope. Most of them are making the same handful of errors.
Why These Mistakes Keep Happening
Boards historically delegated security to IT and the CISO. Approval was a ceremonial step. Article 20 turns it into an accountable act, but the reporting habits, tools, and org charts built for the old model haven't changed. Teams keep delivering what boards used to accept: a summary of the policy. Boards, now aware of their exposure, are starting to ask for proof. That gap is where the mistakes below live.
Mistake 1: Reporting What the Policy Says Instead of What's Happening
Why it happens: Policies are easy to summarize. Operating reality is messy, and nobody wants to put unresolved exceptions in front of directors.
Consequence: The board approves measures on paper while the real environment drifts. A policy requires MFA and prompt account removal at departure, but old accounts remain active and MFA exemptions sit unreviewed. When an assessor tests, the distance between the approved policy and observed practice becomes a finding, and directors can't claim they exercised oversight.
Fix: Restructure board reporting around exceptions. For each access control the board approved, show the policy requirement, current compliance, and the open exceptions: stale accounts, excessive privileges, unreviewed MFA exemptions, and supplier access that has outlasted its contract. Treat the exception list as the primary content, not an appendix.
Mistake 2: Assigning Access Risk to Someone Without Authority
Why it happens: Risk ownership defaults to the CISO because security is "their area." Nobody checks whether that person controls the budget, systems, or people needed to fix anything.
Consequence: Known problems linger. The CISO is accountable for a risk but depends on another team's resources to close it, and the board never learns the fix is stalled for lack of funding or cooperation.
Fix: When you brief the board, state who owns access-control risk and whether that person has authority to act. If remediation depends on another team's budget, say so explicitly and ask for a decision. Document the dependency in your Risk Treatment Plan with a named approver. Some national laws go further; Greece's transposition requires an appointed, suitably qualified Information and Communication Systems Security Officer with adequate resources, independent of the data protection officer. Even where that isn't mandated, the principle is sound.
Mistake 3: Translating Technical Findings Badly
Why it happens: Security teams report in the language they work in: percentages of accounts, control IDs, tool alerts. Directors need to decide, not decode.
Consequence: A failed MFA rollout or over-privileged administrators gets noted and ignored because nobody framed what leaving it unresolved means. The board can't act on what it doesn't understand, and later it can't show it was informed.
Fix: Pair every significant access issue with a risk statement, an owner, a decision requested, and a deadline. Credential abuse is a useful anchor. Verizon's 2026 Data Breach Investigations Report found it in the chain of 39% of breaches, more than any other vector, so directors should expect an answer on which accounts reach critical systems and who controls them. Use a Scenario-Based Risk Assessment to show what a specific gap could enable, in business terms.
Mistake 4: Being Unable to Prove Who Has Access, and Why
Why it happens: Access evidence lives in identity providers, ticketing systems, spreadsheets, and email approvals. Nobody built it to be retrieved on demand.
Consequence: When a regulator, auditor, or director asks the basic question, the answer takes weeks to assemble, or can't be assembled. For ISO/IEC 27001 and SOC 2 programs, this is the same weakness that produces Nonconformities in access reviews.
Fix: For every critical system, be able to show who can access it, why access was granted, who approved it, how long it's valid, and when it was changed or revoked. Test retrieval quarterly. If you can't produce that record in a single sitting, the evidence process is the problem, not the individual control.
Mistake 5: Treating Board Training as a Checkbox
Why it happens: Article 20 requires training for management body members, and it's easy to satisfy with a generic annual session.
Consequence: Directors who can't read an access exception report can't exercise meaningful oversight. Training that doesn't connect to the decisions they actually make adds no protection for them or the organization.
Fix: Tie training to the reporting you deliver. Walk directors through a real exception report, explain what a privileged-access gap means, and rehearse the questions they should ask. Record attendance and content as evidence.
Prevention Checklist
- Board reports lead with open access exceptions, not policy summaries.
- Every access risk has a named owner with documented authority over budget and resources.
- Dependencies on other teams are escalated to the board with a decision requested.
- Each reported issue carries a plain-language risk statement and deadline.
- You can produce who has access, why, who approved it, validity period, and change history for critical systems on demand.
- Retrieval of that evidence is tested on a schedule.
- Supplier access is reviewed against contract status.
- MFA exemptions have expiry dates and review records.
- Director training uses real reporting and is documented.
- Your national transposition requirements, including any security officer appointment, are confirmed and mapped.
If an assessor asked your directors tomorrow what they know about access risk, would their answers match your evidence?
