ISO 27001, NIS2, DORA, KRITIS: One Personnel-Security Checklist for Four Frameworks

Most regulated firms in the DACH region do not run one personnel-security program. They run four. The ISMS team maintains screening records for the ISO 27001 certification body. The CISO keeps a concept file for the BSI under § 30 BSIG. Compliance maintains due-diligence files and a register for BaFin under DORA. And where the company operates critical facilities, a fourth owner answers for §§ 31, 39 BSIG and the KRITIS-Dachgesetz. Four matrices, four evidence packs, four rescreening cycles, four audits — for what is, in substance, the same set of checks on the same people. This article maps the four frameworks onto one personnel-security checklist: where they overlap, where they genuinely diverge, and how to build one shared evidence base instead of four. If you are starting from zero, the personnel-security checklist builds the underlying program first; this one consolidates it across frameworks.

One personnel program, four obligations

The failure mode here is organisational, not technical. Each framework has its own owner, its own auditor and its own vocabulary, so nobody is incentivised to notice that ISO 27001 A.6.1, § 30 BSIG, DORA’s training and due-diligence duties and the KRITIS-Dachgesetz’s personnel measures all describe versions of the same activity: vet people before they get access, proportionally to risk, on an ongoing basis, and write it down. Because the same hire gets checked four times by four processes, inconsistencies are guaranteed — the ISO record says one depth, the NIS2 concept promises another, and an auditor or supervisor who compares them finds the gap for you. Consolidation is therefore not a convenience project; it is what gets you through the audits. One documented programme, mapped to each framework’s anchor, is easier to defend than four half-maintained ones.

ISO 27001 A.6.1: the certifiable floor

A.6.1 sets the operational baseline: screening before employment begins, checks continue on an ongoing basis, and their depth is proportional to business requirements, information classification and perceived risk — bounded by applicable law, regulations and ethics. It is certifiable through the Statement of Applicability and the 2022 control set, which makes it the one framework of the four where an external auditor samples your records against a defined standard. What it is not, is a statute. An ISO 27001 certificate is not, by itself, proof of conformity with the BSIG — the BSI’s position is that it cannot serve as sole evidence in supervisory proceedings under §§ 61, 62 BSIG — and the same logic holds under DORA and the KRITIS-Dachgesetz: supporting evidence, never a substitute for the duty. Treat A.6.1 as the floor your programme must clear, then map upward: how each obligation maps to evidence records is set out in the ISO 27001 control-to-evidence mapping.

NIS2 / § 30 BSIG: the statutory personnel-security duty

§ 30(2) no. 9 BSIG transposes Art. 21(2)(i) of the NIS2 Directive (EU) 2022/2555 and expressly requires concepts for personnel security, access control policies and asset management — so personnel vetting is a named, statutory measure category, not an interpretation. Supply-chain security — which pulls contractors and providers into the same concept file — is a separate named category under § 30(2) no. 4 BSIG. § 38 BSIG adds the personal dimension: senior management must approve and oversee the risk-management measures, a duty that cannot be fully delegated. Registration under § 33 BSIG and incident reporting under § 32 BSIG run in parallel. The practical difference from ISO: there is no certificate to earn, only a supervisory process with fines. For the full statute walkthrough, see NIS2 personnel security after § 30 BSIG; for a status check before consolidation, the ten NIS2 readiness questions.

DORA: ICT awareness training and the third-party register

DORA — Regulation (EU) 2022/2554, applicable since 17 January 2025 — addresses people on two tracks. On the training track, Art. 13(6) requires ICT security-awareness programmes and digital operational resilience training for all employees and senior management staff, at a complexity commensurate with their functions; the management body itself trains under Art. 5(4). On the provider track, Art. 28 requires pre-contractual due diligence on ICT third-party providers and a register of information on all contractual arrangements — with responsibility remaining at the financial entity, never contracted away. Art. 30 then sets minimum contract content: service descriptions, rules on subcontractors, termination rights for all ICT contracts, and full access, inspection and audit rights where the contract supports critical or important functions. The personnel-security overlap is direct: your own people with access to critical ICT systems are vetted by your programme, and the provider’s staff are covered by the due-diligence file and the register entry. The details for German financial entities are in DORA’s personnel and third-party requirements.

KRITIS-DachG and SÜG: the sector overlay

Two regimes attach on the KRITIS side, and they are best kept apart. The KRITIS-Dachgesetz — § 13 together with the CER Directive (EU) 2022/2557 — treats personnel security as a distinct set of obligations alongside structural and technical measures, and Art. 14 CER provides for background checks carried out by authorities at the operator’s request, where national law provides for them: a sovereign procedure, not an employer programme. The cyber proof is the second regime: operators of critical facilities demonstrate their measures to the BSI under § 39 BSIG (until December 2025 § 8a BSIG), and where an operator relies on ISO 27001 to support that proof, the certification and the personnel programme must actually interlock — the examiner of the critical service asks about the people who operate it. One caveat from practice: state procedures such as the SÜG security clearance cover only certain roles, test narrowly against sovereign interests, and return a binary result — they do not fulfil the operator’s own personnel-security duty. The implementation path is described in the background-checks implementation guide, the statutory timeline in KRITIS-Dachgesetz duties and deadlines.

The mapping table: one requirement, four anchors, one record

The point of consolidation is that most requirements resolve to the same artifact. This table maps the recurring duties to the shared record that can support each of them:

Read column by column, the table also exposes the gaps: anything a framework names that the others do not — the register content prescribed for DORA, the § 39 BSIG proof interface — must stay a deliberate line item, not disappear into the merge.

Where the frameworks genuinely diverge

Three divergences survive any honest consolidation. First, statutory versus certifiable: ISO 27001 is voluntary and earns a certificate; § 30 BSIG, DORA and the KRITIS-Dachgesetz are duties backed by supervision and fines — dropping a named measure category is not an optimisation, it is an omission. Second, scope: the recast BSIG covers around 29,500 entities as particularly important or important; DORA applies to financial entities; the KRITIS regime applies to operators of critical facilities — your firm may be in one, two or three of them, and the mapping must reflect the actual set, not a generic worst case. Third, the audience: a certification body samples records, while BSI and BaFin review concepts and their implementation — supervisor-facing documents must state the approach, the risk basis and the approval, not just the result.

Building the shared evidence base

One screening matrix, one rescreening log, one evidence format — extended with a column per framework. Every check is documented with dated sources, the decision that relied on it, and a human final review, so the same record serves the ISO auditor’s sampling and a supervisor’s concept review. That is also where the GDPR boundary holds: the screening file is a per-person record that needs a lawful basis — § 26 BDSG is the traditional anchor, though its standalone status has been doubted since the CJEU’s C-34/21 judgment, so the safest framing is Art. 6(1) GDPR with § 26 as an interpretive aid, and the necessity documented per role in the matrix is what carries the check. Art. 22 GDPR, in turn, prohibits decisions with legal or similarly significant effect that rest solely on automated processing — the four-eyes review is not just good practice, it is the common denominator that lets one file serve each framework’s review on its own terms. The Indicium report is built as exactly that shared artifact: dated sources, documented decisions, human final review — how each framework’s obligations map to it is documented per framework, including for NIS2 and KRITIS.

A 30-day consolidation plan

• Days 1–5 — inventory: list every personnel-security artifact that exists for any framework: matrices, concepts, provider files, training records, rescreening logs. One owner, one table.
• Days 6–12 — gap list: map each artifact against the four frameworks’ anchors from the table above. Mark the duties that only one framework names — they become explicit line items.
• Days 13–19 — extend the matrix: take the role-based screening matrix and add the per-framework columns. Where depths differ, take the strictest coherent value and document why.
• Days 20–25 — unify the evidence: one format per person: dated report, decision note, reviewer sign-off. Migrate existing records only where the format blocks audit use — completeness beats reformatting.
• Days 26–30 — approve and trigger: submit the consolidated concept to senior management for approval under § 38 BSIG, wire the rescreening triggers, and document the date the four programmes became one.

Frequently asked questions

Does our ISO 27001 certificate satisfy NIS2?

No. The BSI’s position: an ISO 27001 certificate is not NIS2 or BSIG conformity and cannot serve as sole proof in supervisory proceedings under §§ 61, 62 BSIG. The certificate remains useful — it evidences the ISMS floor — but § 30 BSIG’s named measure categories need their own documented concept, and management approval under § 38 BSIG is a separate, personal duty.

Is the DORA register of information the same as our ISMS supplier list?

No. Art. 28 DORA requires a register of information with prescribed content on all contractual arrangements with ICT third-party providers, and Art. 30 sets minimum contract terms — termination rights for all ICT contracts, full audit rights where critical or important functions are supported. An ISMS supplier list can feed the register, but the register’s content requirements are stricter and supervision-facing.

Where does KRITIS actually require personnel checks?

The KRITIS-Dachgesetz treats personnel security, in § 13 together with the CER Directive, as a distinct obligation set for critical facilities; Art. 14 CER provides for background checks carried out by authorities at the operator’s request, where national law provides for them. On the cyber side, where an ISO 27001 certificate supports the proof under § 39 BSIG, the personnel programme must interlock with it. A state SÜG clearance, where it exists, covers only certain roles and does not replace the operator’s own duty.

This article provides general information and does not constitute legal advice.