The change is finished on the first day. It goes live at the end of the week.
A team adds a feature to a service it already owns. Writing it takes a day. To run, it needs a database, a place to put uploads, and its own URL with TLS and single sign-on in front of it. All of that is standard, all of it is already running elsewhere in the organisation, and none of it is in the team’s hands.
Everything it needs to run already exists in the organisation, as a pattern someone else is running today.
Platform for the database and storage, the web team for the exposed URL and its certificate, identity for SSO. Separate backlogs, one dependency chain.
Which storage tier, who owns the data. Four minutes to answer, a day and a half after it was asked.
Small, automated and reversible, and it still needs a form, an agenda slot and a presenter. The board sits weekly.
Scan output, approval record, configuration as it went live. Three systems, none of them in the format the auditor asked for.
Under an hour of engineering inside four days of elapsed time. The next change starts the week over again.
This is why teams batch releases instead of shipping them right away.
Nothing joins the pipeline, the registry, the ticket and the control sheet together except a person with four tabs open. Even a routine change pays much of the same toll.
of a developer’s week goes to everything other than writing or improving software.
Sources: Tidelift and The New Stack, Developer Survey (32% writing or improving code, 35% maintenance, testing and security, 23% meetings and operational tasks); research cited from Carnegie Mellon puts new code at 20–25% of developer time; Atlassian and DX, State of Developer Experience 2024: 69% lose eight hours or more per week to organisational inefficiency alone.
The same engineers carry the compliance load.
NIS2 expects an early warning within 24 hours and a notification within 72. Posture and control state sit spread across tools and spreadsheets, so the state of things has to be reconstructed afterwards.
The ten measures in NIS2 Article 21 have to be implemented and continuously evidenced. In practice people collect that evidence from several tools, ahead of every audit.
Golden paths, not golden cages.
Most platforms buy safety by taking choices away. We want the opposite.
The constraint is on being compliant and secure, not on being conventional.
One standard piece of infrastructure that already carries the security and compliance work: a web server, a database, storage, TLS, SSO.
A complete, deployable stack assembled from those blocks, with the pipelines and policies that belong to it.
An organisation holds one or more tenants; a tenant holds stacks; a stack runs in its environments. Isolation is enforced at tenant level and at stack level.
The platform is the path from code to production.
Because it is the path, the evidence that the path was secure and compliant comes out of walking it, instead of being written up about it afterwards. Engineers declare their stack in the portal, test it, and promote it forward themselves. Nothing in the loop waits on another team’s backlog or a weekly meeting.
Only blocks and applications that are secure and compliant get deployed.
The same policy is enforced at four points along the path. Every promotion is approved by a person and recorded.
Each policy carries the control it satisfies and the evidence it leaves behind.
A policy is not a document that describes intent: it runs, it blocks, and the record of it running is the evidence an auditor asks for.
Code is scanned for known vulnerabilities before the change merges.
Evidence: Scan result per commit, with findings and severity.
Every deployable image has a known composition and vulnerability state.
Evidence: SBOM and scan report per image digest.
Deployments with vulnerabilities or forbidden configuration are blocked. No privileged containers.
Evidence: Admission decision per deployment, naming the policy that rejected it.
Running environments keep being evaluated, not only at deployment.
Evidence: Control state per environment, with history.
Deviation and failure are raised while they are happening.
Evidence: Alert record with the environment and the triggering signal.
Encryption in transit and authentication come with the block.
Evidence: Block version and configuration recorded per environment.
NIS2 gives you 24 hours, then 72. The answer should already exist.
What makes the deadline hard is not the writing. It is reconstructing what was running, what changed and who approved it, from tools that were never joined up. That record is kept as the work happens.
An alert names the environment and the signal that triggered it.
Which environments are affected, and the control state and policy results at that moment.
The change history behind it: what was deployed, what was scanned, who approved the promotion. Exported to your GRC system.
The mapping is maintained per framework, and an organisation can extend it with its own controls. It is a mapping, not a certification: it shows which clause a passing policy speaks to, and gives your auditor the record to judge it on.
The same result answers four different questions.
The answer arrives in your own workflow, pointed at the specific thing that breaks, while you still have the change in your head.
A regression or a newly published vulnerability comes back as work on your stack, with the environment it affects named, instead of as an audit finding months later.
Teams start from blocks you approved and maintain in one place, so the plumbing and the intake tickets stop landing on your queue.
One surface for every stack and environment you are responsible for, rather than a dashboard per concern and an integration between them.
Your policy set is the gate, so configuration that breaks it never becomes a running environment in the first place.
Drift and misconfiguration surface as they happen, not at the next review.
Every change is a versioned commit with a named approver, so the change record exists before the deployment does.
Control state per environment is kept with history and exported to the system of record you already use, over CSV, XML, JSON or API.
Where it runs.
The option we expect most teams to take: the platform operated for you, on infrastructure that stays inside the EU and under EU jurisdiction.
Run it yourself
On your own bare metal, hypervisor or cloud account. Your infrastructure, your jurisdiction, your operational control.
The choice is yours, and it does not change the product.
Then get in touch.
MosaStack is in the prototype phase and being built now. There is no product generally available yet and no certifications. If you recognise the problem, we would like to hear how you run things today and whether this is heading somewhere useful.