Security and Compliance Engineering for EU Software Vendors
NIS2, DORA, AI Act and CRA readiness delivered as engineering work — gap analysis, remediation plan, and the team to do it.
Most compliance advice stops at the point where the work starts. You get a gap analysis, a register of controls, and a slide saying you are 62% ready — then someone has to go and change the software. That part is engineering, and it is the part we do.
NIS2, DORA, the AI Act and the Cyber Resilience Act all eventually land on the same set of concrete changes: know what you ship and where it came from, be able to prove how a change reached production, detect and report an incident inside a fixed window, and show the controls actually run rather than merely existing on paper. We work backwards from the obligation to the pull request.
We are not a law firm and we do not certify anyone. If you need a legal reading of whether an obligation applies to you, get counsel — and we will happily build against whatever they conclude.
What you get
A gap analysis that names files, not themes
Findings tied to repositories, pipelines and services, with an owner and an effort estimate. "Improve access governance" is not an action. "Service accounts in the billing service share one credential, here is the rotation plan" is.
Evidence generated by the system, not by a person
Audit trails, SBOMs, and release records produced by the pipeline as a by-product of shipping. Compliance work that depends on somebody remembering to update a spreadsheet decays the week after the audit.
A remediation plan sequenced by deadline and risk
What has to be true by the regulatory date, what is genuinely urgent regardless, and what is worth doing once the deadline stops driving the roadmap.
Included
- NIS2 / DORA / AI Act / CRA gap analysis against the codebase
- Secure SDLC aligned to NIST SSDF
- Threat modelling built into sprint planning
- OWASP ASVS adopted as a release standard
- SBOM generation and dependency/supply chain controls
- Incident detection, response runbooks and tabletop exercises
- Prioritised remediation plan with owners and effort
- Engineering capacity to execute the remediation
Selected work
A few projects where this was the job.
Circuit
Digital asset security platform for managing and protecting cryptocurrency vaults. Features multi-provider integration for connecting various wallet and custody solutions, organisation-level access controls, and a sleek dark interface designed for security-conscious users managing digital assets.
aidCare
Healthcare marketplace connecting families with professional caregivers and personal assistants. Features specialist search, detailed profiles with experience and specializations (elderly care, mobility, children, palliative care), ratings and reviews, messaging, and hourly rate transparency for easy hiring.
ARMA Connect
Compliance management platform designed for property managers to track electrical inspections (EICR), PAT testing, emergency lighting, and lightning protection across multiple sites. Features interactive dashboards with real-time status visualization, inspection scheduling, and document management.
Common questions
Are you auditors? Can you certify us?
No, and we will not pretend otherwise. We are the engineering side. We find the gaps in the software and the delivery process, we build the fixes, and we make sure the evidence an auditor asks for is produced by the system rather than assembled by hand the week before. If you need certification or a legal opinion, you need an auditor or counsel — we work alongside both regularly.
We already have a compliance consultant. Where do you fit?
Usually directly downstream of them. They tell you which obligations apply and what the control framework should look like; that output is often a register that nobody on the engineering team knows how to action. We translate it into backlog items against real services, then build them. The two roles do not overlap much in practice.
How long does a gap analysis take?
Two to four weeks for most mid-size products, depending on how many services and pipelines are in scope. We need read access to the repositories and CI, an intro from someone who knows the architecture, and whatever your consultant or counsel has already produced so we are not re-deriving the obligations.
Does this slow delivery down?
It does if you bolt it on at the end, which is how it usually goes wrong. Threat modelling at sprint planning costs about an hour. Retrofitting an access control model into a system that shipped without one costs a quarter. Most of what we do is moving the work earlier so it stops arriving as an emergency.
Our deadline is close. What can realistically be done?
Say so on the first call and we will scope backwards from the date. Typically the first fortnight establishes what is genuinely mandatory versus what has accumulated on the list, because those two sets are rarely the same size. Some obligations are a configuration change. Some are a quarter of engineering. Knowing which is which early is most of the value.
