Policy scanner or officer workspace
Two approaches promise to make compliance demonstrable. One reads source code, architecture documents and policies automatically and reports deviations from a stored rule set. The other gives an appointed person a place of work in which their statutory duties run as tasks, trainings, audits and documents. Both produce evidence, but for different sentences of the same statute. This page sets those sentences side by side in their own words and names what a scanner evidences, what a workspace evidences, and what neither of them replaces.
Two approaches compared
| Criterion | Automated policy scanner | Officer workspace |
|---|---|---|
| What is checked | Artefacts: source code, architecture diagrams, technical documentation, configuration. Whatever exists as a file gets checked. | Duties: the statutory tasks, instruction sessions, audits and documentation obligations of an officer role. What gets checked is whether they were done and evidenced. |
| What it is measured against | A stored rule set — an internal security policy, a technical standard, a norm. The operator supplies the rules; the scanner checks against them. | The statutory text and the catalogue of duties that follows from it for the role. Templates carry the provision they are meant to satisfy in their name. |
| What comes out | A finding: location, rule breached, severity. Who deals with it and by when is not part of the finding. | A task: owner, due date, recurrence and history. A finding only becomes evidence once somebody has worked it off. |
| What it evidences | A measure under § 30(2) no. 5 BSIG — security in acquisition, development and maintenance — and a procedure under § 30(2) no. 6 BSIG for assessing effectiveness. That is genuine evidence, not decoration. | The documentation of compliance under § 30(1) sentence 3 BSIG and management's duty to implement and supervise under § 38(1) BSIG — that is, that somebody owned the measures and supervised their implementation. |
| What it does not replace | No designation under Art. 37 GDPR, no conformity under § 14 BFSG, no legal assessment of an individual case. A scan has no letter of appointment and no reporting line. | No look into the source code. Whether an application meets its security policy is not something the workspace says; it records that somebody checked and what followed. |
| Who assesses | The rule set. What the rule does not know, the scanner does not find; what the rule states too strictly, it reports as a breach. | The appointed person, with their expertise. Templates and checks structure the question; the decision is made by the human holding the role. |
| Repetition | Per run — on every change, every release or on demand. The advantage is frequency. | As a cycle — annually, quarterly, on a trigger. The advantage is completeness across all duties of a role. |
| History | One report per run. Whether and how a finding was fixed only shows in the next run — or in a second system. | One continuous file: who did what and when, with the record attached. Exactly what inspectors ask for. |
| Cost structure | Depending on the provider, per check, per data source or as a licence. The range is wide; we do not quote third-party amounts. | A running price per role per month — with CIVAC, EUR 49 and publicly stated. Appointed officers are priced individually. |
About these statements: This page is for orientation and is not legal advice. It compares two organisational models in general rather than the offerings of particular providers; statements about automated scanners describe the category, not any individual product. Statutory quotations were taken from the official text; German statutes are quoted in our own translation and the German text is authoritative. The legal position is as at the time of writing (September 2026) and may have changed. Whether your entity falls under §§ 30, 38 BSIG depends on sector and size and has to be examined in the individual case.
What a scanner evidences — in the statute's own words
For essential and important entities, § 30(2) of the German BSI Act (BSIG) lists what risk-management measures must “at least” comprise. Two of its numbers describe precisely what an automated scanner does. In our translation of the German text, number 5 requires “security measures in the acquisition, development and maintenance of information technology systems, components and processes, including the management and disclosure of vulnerabilities”. Number 6 requires “concepts and procedures for assessing the effectiveness of risk-management measures in the field of information technology security”.
A scanner that checks source code and documentation against a security policy on every change is a security measure in development within the meaning of number 5 and a procedure for assessing effectiveness within the meaning of number 6. Its reports are evidence of both. Anyone running such a check should therefore not treat it as a side matter but as what it is: one of the measures whose observance § 30(1) sentence 3 BSIG requires to be documented.
What the statute requires alongside it — and who owes it
The same section ends with a sentence no scan produces. § 30(1) sentence 3 BSIG reads, in our translation: “Compliance with the obligation under sentence 1 shall be documented by the entities.” What is meant is compliance with the entire obligation — all ten numbers of subsection 2, from risk analysis via supply-chain security to training and access control. A scan report documents numbers 5 and 6. The remaining measures are tasks, instruction sessions, contracts and concepts, and their documentation arises where that work takes place.
Added to that is a duty which falls not on the entity but on its management. § 38(1) BSIG reads, in our translation: “Management bodies of essential entities and important entities are obliged to implement the risk-management measures to be taken by those entities under § 30 and to supervise their implementation.” Implementing and supervising are activities of persons. They can be evidenced — through ownership, deadlines, reports and a history showing who decided what and when. An officer workspace is where that evidence comes into being; a scanner supplies one of its inputs.
What an appointed person replaces — and what CIVAC is not
Three duties cannot be met by any scan, because the law ties them to a person or to a statement of conformity. First, designation: under Art. 37(1) GDPR the controller and the processor “shall designate a data protection officer in any case where” one of the three conditions listed there is met; § 38(1) sentence 1 of the German Federal Data Protection Act (BDSG) extends the duty to private bodies which, in our translation, “as a rule constantly employ at least 20 persons in the automated processing of personal data”. Second, conformity: under § 14(1) BFSG, the German Accessibility Strengthening Act, a service provider may offer or provide its service only if the service meets the accessibility requirements and the provider has produced and made accessible the information under Annex 3, and under § 14(3) BFSG the provider must ensure that the requirements are met at all times. A scan is an indication at a point in time; the duty is continuous and rests on the provider.
Third, legal advice. § 2(1) of the German Legal Services Act (RDG) defines a legal service, in our translation, as “any activity in specific third-party matters as soon as it requires a legal examination of the individual case”, and § 3 RDG declares its independent provision inadmissible unless permitted by law. CIVAC is not a law firm. Neither a scanner nor the workspace nor this page examines your individual case legally. The workspace indicates risks, maps them to a provision and turns them into tasks; the legal assessment is made by your appointed person or by someone authorised to give it. Where a case reaches that boundary it belongs with a lawyer — and the workspace records that, and when, it was handed over.
When each approach fits
A scanner fits when …
- you develop or operate software yourself and security policies exist as documents.
- measures under § 30(2) no. 5 and no. 6 BSIG are to be evidenced, especially with frequent changes.
- findings are worked off anyway by a development team that uses its own task tooling.
- the object of the check exists in full as code, diagram or file.
A workspace fits when …
- the law requires a named person — under Art. 37 GDPR or § 38 BDSG, for instance — and that person's work has to be demonstrable.
- the documentation duty under § 30(1) sentence 3 BSIG and the supervision duty under § 38(1) BSIG are to be evidenced.
- several officer roles need the same task, training and audit logic.
- an inspection is coming and the question is who did what and when.
Frequently asked
- Does an automated code scan satisfy the NIS 2 duties?
- Part of them. § 30(2) BSIG lists ten areas that risk-management measures must “at least” comprise. A scanner that checks code and documentation against a security policy is a measure under number 5 — security in acquisition, development and maintenance, including the management and disclosure of vulnerabilities — and a procedure under number 6 for assessing effectiveness. The other eight numbers, the documentation duty under § 30(1) sentence 3 BSIG and management's duty to implement and supervise under § 38(1) BSIG are untouched by it.
- Can a scanner replace the data protection officer?
- No. Art. 37(1) GDPR requires the controller and the processor to “designate a data protection officer in any case where” one of the conditions listed there is met, and § 38(1) sentence 1 BDSG extends the duty to private bodies which as a rule constantly employ at least 20 persons in the automated processing of personal data. What is designated is a person — under Art. 37(5) GDPR “on the basis of professional qualities and, in particular, expert knowledge of data protection law and practices”. A tool has neither, and it cannot carry the contact details that Art. 37(7) GDPR requires to be published.
- Is a green scan enough as evidence of accessibility under the BFSG?
- No. § 14(1) BFSG ties the offering of a service to two conditions: the accessibility requirements must be met, and the provider must have produced and made accessible the information under Annex 3. § 14(3) BFSG requires that the requirements are met at all times, and § 14(4) BFSG obliges the provider, in case of non-conformity, to take corrective measures and to inform the market surveillance authority. An automated scan is a technical indication at a point in time. It is a good starting point for the task list, but not a statement of conformity.
- What is the difference between a finding and a task?
- A finding says that something deviates from a rule: location, rule, severity. A task says who will deal with it by when, and keeps what became of it. For the duties under § 38(1) BSIG — implement and supervise — the second step is the decisive one, because what has to be evidenced is not the state at a point in time but that somebody owned it. In the CIVAC workspace every finding from a check becomes a task with an owner and a date in one click; the history stays attached to the task.
- Does CIVAC itself use automated checks?
- Yes, within clear limits and without looking at source code. The workspace contains checks that read a public website against liability areas or scan pages with a testing engine against WCAG 2.1 AA. Their results are labelled as an indication, not a statement of conformity, and every finding becomes a task. What CIVAC does not do: check source code, architecture documents or your internal security policies. For that, a scanner of the category in the left-hand column is the right tool — and its report a good attachment to the task that evaluates it.
- Can both approaches run alongside each other?
- That is the sensible normal case for any entity that develops software and also has officer duties. The scanner supplies the evidence for § 30(2) no. 5 and no. 6 BSIG at the frequency development needs. The workspace holds the remaining measures, the documentation under § 30(1) sentence 3 BSIG and management's supervision under § 38(1) BSIG as tasks, cycles and history. In practice that means the scan report becomes an attachment to a recurring audit, and open findings become tasks with an owner — not a PDF that the next run overwrites.