Example audit: questions and evidence

An audit – by the competent authority under Article 32 or 33 of the NIS2 Directive, an audit that your national law requires, or a certification under ISO/IEC 27001 – asks about access to the databases that are reachable through WKL Database Gateway. This example shows six typical questions. For each it names the evidence, the way to it in the administration app and the limit of the evidence that you should address openly.

The names, dates and figures in the example are made up.

Preparation

In the area Protokoll (Log), under Weitere (More) > Nachweisberichte (Evidence reports), create the Rechteübersicht (Rights overview) and the MFA-Abdeckung (MFA coverage) on the day before the audit, plus Austritte und Sperren (Departures and locks) and Verwaltungsänderungen (Administration changes) for the audit period, for example the last twelve months.
Store the Excel and PDF files where the logs belong, and add the reports of earlier dates that you created regularly.
Keep the administration app open to show individual cases live.

How the reports are created and what they contain: How to create evidence reports.

Question 1: Who may access which data?


Evidence	report Rechteübersicht: every person with status, second factor, Windows account, SQL login, rules and number of valid keys; every rule with its entries
Way	hand over the PDF; for follow-up questions filter the Excel file by rule or person. For a single person live: Personen und Schlüssel (People and keys), select the person, Rechte (Rights) > Anmeldung und Rechte … (Sign-in and rights) shows what they may do from which network
Limit	members of Windows groups and permissions inside the databases aren't in the report; Active Directory and SQL Server show them

Question 2: Do all people sign in with multi-factor authentication?


Evidence	report MFA-Abdeckung: totals and names of the active people by second-factor status, the sign-in rules that require a code, and the valid keys marked Ohne zweiten Faktor (Without second factor)
Way	the totals show the coverage; the list of keys without a second factor is the list of justified exceptions, for example a key for Power BI. For the administration itself, the data service requires the code with every sign-in method
Limit	whether a sign-in rule applies also depends on the network and the sign-in method; the rules are in the report, the check per network is in Anmeldung und Rechte …

Question 3: Was Mr. Example's access revoked when he left on 30 June?


Evidence	report Austritte und Sperren for the period: disabled account, revoked keys, ended sessions, removed rules, each with time in UTC and actor
Way	show the person's rows in the report. Live: Protokoll, tab Änderungsprotokoll (Change log), expand day and actor; each row shows the values before and after
Limit	the operator locks the Windows account and SQL logins where they are managed; that lock isn't in the report

Question 4: Who changed the sign-in policy, and what was set before?


Evidence	report Verwaltungsänderungen for the period: every change to rules, sign-in policy, data sources, identities, assignments, settings and mail templates with the values before and after
Way	filter the report by the set of sign-in rules. Long values are cut after 1,500 characters in the report; the tab Änderungsprotokoll shows them in full
Limit	the change log isn't tamper-proof: anyone who may write the data service's store file on the server can change it. Therefore show who has write access there, and keep reports outside the server

Question 5: Show me a refused access attempt and its cause.


Evidence	tab Audit in the area Protokoll: per access time, caller, resource, result and status, and for a refusal by a sign-in rule its number and version. Area Anmeldungen (Sign-ins): refused sign-ins and wrong codes by origin
Way	on the Übersicht (Overview), click the card Abgewiesene Anfragen (Rejected requests); the tab Audit opens, filtered to the answers 401, 403 and 429. Expand day and caller; the column Grund (Reason) names the cause
Limit	the audit goes back as far as the data service keeps it (default 365 days). Older periods need a backup of the service's log file; if your national law requires a longer retention, set it in the service

Question 6: How do you learn about vulnerabilities in the software, and how quickly do you install fixes?


Evidence	`SECURITY.md` and `MANUFACTURER.md` of the delivery: point of contact, handling of reports, support period; the Product and security information under CRA Annex II
Way	show the version in the entry `version` of the file `deploy/app-manifest.json`; show your procedure for putting new versions in place (Put a new version in place)
Limit	how quickly fixes are installed is decided by your patch process; the app doesn't download any version by itself

What the audit often asks next

Regularity: reports from several dates show that rights and the coverage of multi-factor authentication are reviewed continuously, not only for the audit.
Responsibilities: who has the right admin (rights overview) and who may write the store file on the server (permissions in the server's file system).
Deletion policy: how long the change log, the audit and filed reports are kept; see Security and privacy.