NIS2 and national cybersecurity law

Run the information security office of an essential or important entity from one registry of suppliers, assets, risks, incidents, vulnerabilities, threats and tasks.

Typical requirementsNIS2 (EU) 2022/2555Nacionālās kiberdrošības likumsMK noteikumi Nr. 397ISO 27001

Who it is forEssential and important entities under NIS2, including state and municipal bodies and private operators covered by the Latvian National Cybersecurity Law.

NIS2 asks for more than a set of documents. The entity must know what it runs, who it depends on, which risks it carries and how incidents are handled, and its management body must approve and oversee the measures. In Latvia, the National Cybersecurity Law (Nacionālās kiberdrošības likums) transposes NIS2, and Cabinet Regulation No. 397 sets the minimum cybersecurity requirements, from governance and the cybersecurity manager role to incident classification, backups, encryption and outsourcing. Significant incidents are reported to CERT.LV, the national CSIRT, following the classification and reporting guidelines of the regulation, and entities submit a cybersecurity self-assessment report that evaluates how each requirement is met.

WINGMAN keeps these as linked registers in one model, the way an ISO 27001 ISMS would. The information security office works from one source: what the supervisor, the auditor and the management body see is what the office runs on. The incident reports and the self-assessment report are generated from the same records, so they match what is actually in place.

Videos

**ISMS implementation with WINGMAN AI** Building an information security management system in WINGMAN, from requirements and scope to risks, controls, owners and the review cycle.

**WINGMAN AI GRC – supplier assessment automation** Automating supplier assessment with WINGMAN AI, from registering the supplier to the evaluation, the decision and ongoing monitoring.

Plays from youtube-nocookie.com. YouTube sets no cookies until you press play.

Registers WINGMAN keeps

Each register is a set of linked records in one model, not a separate spreadsheet. Pick an entity to see it in the data model.

Suppliers

Supply-chain register

Each supplier with the services it provides, the data it touches, its criticality, contract terms and evaluation date. Supplier incidents and notices link straight to it.

Assets

Asset and service inventory

Services in scope of the law, the systems and data they run on, owners and criticality, with dependencies drawn as links.

Risks

Risk register

Risks per service, rolled up into entity-level risks, with likelihood, impact, treatment and the controls that reduce them.

Incidents

Incident register and cyber incident log

Timeline, classification against the regulation's criteria, reports to CERT.LV with their deadlines, and lessons learned linked back to risks.

Vulnerabilities

Vulnerability register

Findings from scans, pentests and advisories, located on assets, with remediation tasks and due dates.

Threats

Threat register

Actors and events relevant to the sector, fed by threat intelligence signals and linked to the risks they drive.

Conclusions

Self-assessment results

The fulfilment level of each requirement with the controls and evidence it rests on, generated into the self-assessment report and comparable from one cycle to the next.

Requirements

Requirements catalogue

The articles of the law and the minimum requirements of the regulation, one record per requirement, mapped to ISO 27001 and to controls.

Tasks

Work plan

Corrective actions, treatment tasks and recurring reviews, each with an owner and a due date, rolled up into the annual plan.

The governance cycle on the model

Step through how the regulation runs on WINGMAN records, from scope to proof.

Stage 1 of 7
Scope and registration
Services that fall under the law are recorded as assets, with the systems, data and suppliers they depend on. That map is the scope.
Assets Suppliers Requirements
Links used
1. Assets depends on Assets
2. Suppliers provides Assets
WINGMAN and AI support
Drafts the service map from existing system, contract and procurement records.
Decides: The cybersecurity manager confirms the scope.
Stage 2 of 7
Minimum requirements mapped
Each requirement of the law and the regulation is a record, mapped to ISO 27001 clauses and to controls already in place. Gaps are what is left.
Requirements Controls Documents
Links used
1. Requirements maps to Requirements
2. Requirements met by Controls
3. Controls described in Documents
WINGMAN and AI support
Maps the clauses to existing controls and lists those with no control.
Decides: The cybersecurity manager agrees the gap list.
Stage 3 of 7
Risks, threats and vulnerabilities
Risks sit on the services in scope. Threats and vulnerabilities make the scenarios concrete and move ratings between reviews.
Risks Assets Threats Vulnerabilities
Links used
1. Risks affects Assets
2. Threats drives Risks
3. Vulnerabilities found on Assets
4. Vulnerabilities raises Risks
WINGMAN and AI support
Proposes risks from the sector threat picture and open vulnerabilities.
Decides: Risk owners rate and choose a treatment.
Stage 4 of 7
Management body accountability
The management body approves the risk management measures and oversees them. Roles carry the duties, so a change of staff does not break the chain.
Roles People Risks Controls Plans
Links used
1. People holds Roles
2. Roles owns Risks
3. Roles owns Controls
4. Roles accountable for Plans
WINGMAN and AI support
Prepares the approval pack and lists records with no owner role.
Decides: The management body approves.
Stage 5 of 7
Incidents and reporting
Signals are triaged into incidents and classified against the significance criteria of Regulation No. 397. A significant incident carries the reports to CERT.LV, from the early warning and notification to progress and final reports, and the follow-up work. The incidents form the cyber incident log.
Signals Incidents Assets Documents Tasks
Links used
1. Signals escalates to Incidents
2. Incidents affects Assets
3. Incidents reported in Documents
4. Incidents followed up by Tasks
WINGMAN and AI support
Proposes the classification with reasons, tracks the deadlines and drafts each report in the structure the guidelines require, from the incident record.
Decides: The incident manager decides what is reported.
Stage 6 of 7
Self-assessment report
The self-assessment report evaluates each formal requirement against the controls in place and their evidence. It is generated from the records, not written from scratch, and the conclusion per requirement is kept for next time.
Requirements Controls Evidence Conclusions Documents
Links used
1. Requirements met by Controls
2. Controls proven by Evidence
3. Conclusions judges Requirements
4. Requirements interpreted in Documents
WINGMAN and AI support
Generates the report. For each requirement it lists the controls, their status and valid evidence, proposes a fulfilment level with reasons, and lists the gaps as tasks.
Decides: The cybersecurity manager reviews; the management body approves before submission.
Stage 7 of 7
Proof and audit
Controls carry evidence with expiry dates. The cybersecurity audit reads the same records the office runs on.
Controls Evidence Audits Findings Tasks
Links used
1. Controls proven by Evidence
2. Audits tests Controls
3. Audits raises Findings
4. Findings resolved by Tasks
WINGMAN and AI support
Lists expired evidence and assembles the audit pack per requirement.
Decides: The auditor concludes; owners fix findings.

Screens for this stage · Stage 2: Minimum requirements mapped

Requirements **A contractual requirement mapped to standard clauses** A customer contract clause (report incidents within 72 h) is met by one control and mapped to ISO 27001 A.5.26 and NIS2 Article 21, so one control satisfies three sources.

Controls **A control, the policy behind it and the clauses it meets** Enforced MFA on all Google Workspace accounts: fully compliant, documented in the technical security policy, applied to two assets, meeting ISO 27001 A.8.5 and A.5.17.

Screens for this stage · Stage 3: Risks, threats and vulnerabilities

Vulnerabilities **An actively exploited vulnerability and the assets carrying it** EPSS 0.952, exploited in the wild, patch available, linked to two assets. The brief names the gap: no owner and no remediation date.

Risks **A risk and everything linked to it** Related tasks, the incident that realised the risk, the control that reduces it, the parent risk, and the risk position with the appetite line.

Screens for this stage · Stage 4: Management body accountability

The Brief **The Brief: state of the programme** Every morning WINGMAN writes the state of the programme from the records: where risk concentrates, coverage and control, a watch list and the tensions between groups of records.

Screens for this stage · Stage 5: Incidents and reporting

Ask Wingman **Draft the notification to the authority** Asked in plain words on the incident, WINGMAN fills the GDPR Article 33 notification from the record: nature of the breach, data subjects, data categories, DPO contact, likely consequences, measures taken, communication to data subjects, other notifications. Every field is marked KNOWN, UNKNOWN or ASSUMED.

Ask Wingman · step 1 **Article 33(3)(a): nature of the breach** Summary, breach type, cause or vector with the three possibilities from the record, linked threat and systems, each marked KNOWN or UNKNOWN.

Ask Wingman · step 2 **Draft customer security notice** Owner, timing, channels, subject and body, with the facts that must be confirmed before sending: wording on the source, whether to publish bank details, payments already made, personal data.

Screens for this stage · Stage 7: Proof and audit

The Brief **Gaps to close and the organisation's temperature** Eleven register checks run on every record: risks without an owner or score, requirements without a control, tasks overdue by more than 30 days, vulnerabilities past the patching SLA, unapproved documents. Each gap links to the records behind it.

Use cases from this angle

The same use cases, with what changes for this regulation.

Operations

Supplier evaluation

Supply-chain security as the law asks for it. Critical suppliers are evaluated before onboarding, and supplier notices reach the risk register.

Operations

Incident handling

Classification against the regulation's significance criteria, then the early warning in 24 hours, the notification in 72 hours, progress reports and the final report to CERT.LV, drafted from the incident record.

Compliance

New requirements

When the law or the regulation changes, the new clauses are mapped to controls already in place and only the real gaps become tasks.

Risk

Risk review and treatment

An all-hazards risk assessment per service, with treatments the management body can approve.

Risk

Vulnerability impact

Advisories from the national CSIRT and scanner results land on the assets that carry them.

Compliance

Management review

The management body sees exposure, incidents, overdue work and approves the measures, with minutes and decisions kept.

Accountability

Roles and RACI

The cybersecurity manager, the management body and control owners are roles with written duties and deputies.

Assurance

Auditing

The self-assessment and the periodic cybersecurity audit run on the same records, with conclusions per requirement.

Questions it answers

Can we show the supervisor what we run, who supplies it and how it is protected?

From the services in scope to the systems and suppliers they depend on, to the risks on them and the controls that reduce those risks.

Which suppliers would hit an essential service if they failed today?

From the service to the assets it depends on, to the suppliers that provide them, with their criticality and evaluation date.

Are we on time with the incident report?

Each significant incident shows the deadlines that apply, what was sent and when, and what remains.

Can we produce the self-assessment report today?

Yes. From each requirement to its controls, their status and evidence. WINGMAN generates the report with a proposed fulfilment level per requirement, and gaps are listed before anyone signs.

Is this incident significant, and what must CERT.LV receive?

The incident record shows the classification against the regulation's criteria with reasons, the reports due and their deadlines, and drafts of each report.

Which minimum requirements have no working control?

Requirements with no control, or with controls whose evidence has expired, appear as gaps before the audit does.