Public Sector
Large programs, many vendors — and you answer for the result.
You rarely build your own software. You specify it, procure it and accept it — usually across several vendors, several years and more than one change of political direction. The delivery capability sits outside your organization. The accountability does not.
Your suppliers will always know more about what they built than any buyer can. That is how procurement is designed to work, and it holds until the moment of acceptance — when the signature is yours.
Three recur in programs of every size, in every member state — whoever is running them.
The tests that decide whether a delivery is accepted are often specified and run by the party being paid for it. You own the decision and its consequences, without an independent basis to defend it.
Failures surface at the architectural boundaries — in API integrations, in data handoffs, in the assumptions each supplier made about the others. No single vendor is accountable for the seam, and no contract gives you the technical view to assign responsibility.
Closed architectures and proprietary licensing, often set by the incumbent, narrow the field for every procurement you run after. By the time that architectural debt surfaces in a tender, reversing it is an unbudgeted modernization program in its own right.
As a public body, you answer to obligations arriving from three directions at once: procurement law, cybersecurity regulation, and the rules governing how the state itself may deploy technology.
Central government entities are in scope regardless of size, regional ones where a risk assessment places them, and local ones where a member state chooses. Accountability for cyber risk measures sits at management level. Targeted amendments proposed in January 2026 are still in negotiation.
Products with digital elements the state procures must meet the essential requirements from December 2027, and their manufacturers have had to report exploited vulnerabilities since September 2026. The obligation lands in procurement terms.
Authorities deploying high-risk AI carry deployer obligations, including a fundamental rights impact assessment. For stand-alone high-risk systems they apply from December 2027.
Award and acceptance decisions must be documented and defensible. A Public Procurement Regulation proposed in September 2026 would replace the three 2014 directives, with more weight on quality, resilience and security.
We work for the buyer. These are the three points in a program where that changes the outcome: what you ask for, what you accept, and what you do when the two stop matching.
Technical requirements and evaluation criteria written so the evidence you will need at acceptance is contractual from the first day — what the supplier produces, in what form, and who is entitled to verify it. The same discipline applies to a US solicitation, where what the authorizing official will need is settled at award rather than at delivery.
- Evaluation criteria that can be scored against evidence rather than claims
- Interoperability and exit terms that keep the next procurement open
Acceptance measured against the requirement as written, by a party with nothing at stake in the delivery being accepted. The result is something you can put in front of an auditor, a court or your successor. Where the program runs under a continuous authorization, the same evidence feeds the ATO package rather than being produced twice.
- Test design and execution independent of the supplier’s own suite
- Every finding traced to the requirement and the contract clause it touches
A technical read on a program already in flight — architecture, code, pipeline and the distance between reported progress and actual progress — while there is still time for the answer to change something.
- Integration risk at the boundaries between vendors, named and assigned
- A written technical position you can take to the steering committee
Less of the audit cycle spent assembling evidence by hand, and an accreditation decision that can be reached sooner — so a capability reaches the people who need it closer to the moment they need it.
Public programs are judged afterwards, on what can be shown. This is where our work concentrates.
Developed and implemented secure software development and deployment practices across more than fifty federal and defense programs.
Co-authored key international software and acquisition baselines, including IEEE 2675 on DevOps and the ISO/IEC/IEEE 24748 and 41602 standards.
Full-scope IV&V on programs where the delivery capability sits outside your organization and the acceptance decision does not.
The seams between suppliers: interfaces, data handoffs, and the assumptions each one made about the others.
SBOM-based analysis of what is actually inside a delivered system, including the components nobody specified.
Whether a supplier’s pipeline produces what its documentation says it produces, measured against the practices the standards set out.
Evidence for AI-enabled systems that answers deployer obligations, rather than describing the model.