Technical security for regulatory requirements
NIS2, the Cyber Resilience Act, the EU AI Act, and DORA require concrete security work from the organizations or products they cover: risk analysis, vulnerability management, secure development, effectiveness checks, training, and more. Which rules apply depends on scope and transitional timelines — not every organization must meet every requirement.
Alongside legal duties, there are standards demanded by contracts or customers, and voluntary models for improving security. I have been delivering exactly that technical implementation for years. Compliance certification, paper gap analysis, and formal sign-off are not part of what I do — that stays with your legal or compliance function.
In short: the rules describe what security measures you need. I help you actually implement them.
Overview: four EU frameworks
| Framework | What it means for those in scope | Possible consequences of non-fulfilment |
|---|---|---|
| NIS2 | In-scope entities must manage cybersecurity proportionate to risk, handle vulnerabilities, and implement suitable organizational and technical measures. | Supervisory measures and possible fines, depending on the case and national transposition. |
| DORA | Financial entities and certain related actors must build digital operational resilience — from ICT risk management through testing and incident handling. | Supervisory measures and sanctions under the applicable rules; there is no single EU-wide fine ceiling. |
| Cyber Resilience Act | Covered products with digital elements must meet security requirements across the lifecycle, including secure development and vulnerability handling. | Required product remediation, possible restrictions on making the product available on the market, withdrawal or recall, and possible fines. |
| EU AI Act | Certain AI systems face additional requirements for risk management, robustness, and cybersecurity — especially high-risk AI. | Required corrective measures, possible restrictions on affected AI systems, and possible fines. |
These consequences are not automatic; they depend on scope, facts, and supervisory practice.
Risk analysis and threat assessment
In-scope organizations are expected to document risk: threats, vulnerabilities, and whether their measures work.
Without a traceable risk analysis, decisions stay speculative: important attack paths stay invisible, controls land in the wrong place, and reviews lack solid evidence.
My Agile Threat Modeling workshops and the Attack Tree Quickstart produce documented threat models with actors, attack paths, controls, and effectiveness ratings. That is a concrete technical contribution — not a substitute for your full regulatory risk analysis.
Vulnerability identification and handling
In-scope organizations are expected to find weaknesses systematically and work them through a repeatable process.
Without that process, attack surface stays unseen, findings pile up without priority, and incidents become more expensive and disruptive than they need to be.
Attack Surface Mapping, Cloud Security Check, and Container Platform Review deliver findings with evidence, risk ratings, and remediation guidance. The Security Sparring Partner helps prioritize results from your own scanning. When threat models exist, the effectiveness of implemented controls can also be checked through Micro Attack Simulations.
Penetration testing
Several frameworks expect effectiveness checks; that does not create a general explicit penetration-testing duty everywhere.
Without realistic testing, it stays unclear whether defenses hold. Weaknesses surface late — often when remediation is under time pressure and more costly.
The Application Pentest and API Security Check are where I test applications and APIs with offensive techniques. NIS2 requires assessing whether measures are effective, but not a general explicit pentest duty. DORA provides for penetration tests; Threat-Led Penetration Testing applies only to certain financial entities. An application pentest is not a DORA TLPT.
Supply chain and development process security
For in-scope organizations and products, secure development and supply-chain security play a central role.
Weaknesses in dependencies, build pipelines, or development processes open attack paths and, for products under the Cyber Resilience Act, can lead to remediation or restrictions on market availability.
My Secure SDLC Process Review assesses the development process against established maturity models. DevSecOps Pipeline coaching brings security scanning into CI/CD: SCA and SBOM, SAST, container scanning, AI-assisted code review. That supports requirements from NIS2 and the Cyber Resilience Act. A single pipeline scan or an SBOM does not replace the overall duty.
Security architecture and system design
Risk-appropriate protective measures should be built into architecture and system design.
Bolting security on later means expensive rework, unnecessary attack surface, and weak evidence for supervisors or customers.
Security Architecture reviews software and system design from a security perspective. Zero trust, microservice isolation, and GenAI-component reviews are possible technical approaches — not methods that every framework expressly mandates.
AI system security
Certain AI systems face additional requirements for risk management, robustness, and cybersecurity — depending on scope and transitional timelines.
Insufficiently secured AI integrations can lead to data exfiltration, manipulated behavior, or missing evidence. Agentic systems, RAG, and MCP are not automatically high-risk AI.
My Agentic AI Security assessment examines technical attack surfaces: prompt injection, tool poisoning, data exfiltration, memory manipulation, and goal hijacking across LLM integrations, RAG pipelines, MCP tools, and agentic architectures. It is a technical contribution, not a full conformity assessment.
Staff training and security awareness
Training and awareness appear in laws, standards, and maturity models — the duty, the audience, and the evidence differ.
Without suitable training or traceable learning outcomes, teams and leadership stay unprepared. For standards and customer requirements, missing evidence can affect audits, certifications or attestations, or contractual demands — not the same consequences everywhere.
On request I produce an evidence pack: a mapping of the modules actually taught against the requirements you name, plus a quiz with a pass mark. You hold that pack; it does not create compliance. A quiz can document learning outcomes, but alone it does not prove lasting effectiveness or full conformity. Technical developer training does not replace suitable leadership training.
The trainings that can carry this pack are the Web Security Bootcamp, the Pentesting Training, and Custom Focus Sessions. The Live Hacking Event is awareness for a mixed audience, including leadership — not the quiz path.
| Framework or standard | Training expectation | My contribution |
|---|---|---|
| NIS2 | Leadership should understand cybersecurity; for staff, cyber hygiene and role-based training are expected, shaped by national transposition. | Mapping and quiz against the duties you name. Not a compliance certificate. |
| DORA | For affected financial entities: awareness and resilience training for staff, plus suitable leadership knowledge; a simplified framework may have its own rules. | Mapping of the staff curriculum; quiz for that curriculum. Leadership track only if that track was delivered. |
| PCI DSS | Industry standard: developers of custom software need regular training on secure development and, where used, on security testing tools. Consequences mainly arise from payment and contractual relationships. | Mapping and quiz for a tailored developer course. |
| BSI IT-Grundschutz | Standard/framework: awareness, training, and traceable learning outcomes; plus training for development teams. | Mapping of modules; quiz as a contribution to documenting learning outcomes. |
| OWASP SAMM | Voluntary maturity model: role-based security training and, where possible, a test of understanding alongside attendance. | Mapping plus quiz as an understanding check; does not replace an attendance record. |
| BSI C5 | Cloud security catalogue, often required by contract or customers: awareness, training and measurement of learning outcomes, plus development-related training. | Mapping to the criteria you have declared applicable. |
| ISO/IEC 27001 | Management-system standard: competence and awareness; secure coding depending on risk-based control selection. | Mapping to the controls you have declared applicable. |
Ongoing security advisory
Rather than buying expertise only in bursts, the Security Sparring Partner provides ongoing access to technical security advisory — closer to the continuous risk management many frameworks and standards expect.
I support technical implementation. Legal assessment and formal conformity decisions are outside the scope of this work.