Product Security
Security built into the software and connected products you sell, from design requirements and release gates to SBOMs, vulnerability disclosure and the evidence your customers ask for.
Service Details
Product security gives you a repeatable way to ship software and connected products that are secure by design, with the evidence to prove it to customers and regulators. You get clear security requirements, release gates your engineers can work with, a process for handling vulnerabilities, and answers ready for the next security questionnaire.
It is part of our assessments and engineering services, and it suits companies that build and sell software, SaaS platforms or connected devices. Where other services test a system at a point in time, product security sets up the programme that keeps every release in shape.
INFO
You get one owner for product security across design, release and support, rather than security work scattered between engineering, sales and legal.
Who product security is for
You are likely to need this if enterprise prospects keep sending long security questionnaires, if a buyer has asked for an SBOM or a vulnerability disclosure policy, or if you sell connected devices to UK consumers. It also fits teams preparing for SOC 2 or selling into the EU, where the Cyber Resilience Act (CRA) is bringing new duties for manufacturers.
Many software teams already have capable engineers. What they often lack is the structure around them: agreed requirements, a defined release bar and a process for when something goes wrong after launch.
What product security covers
The parts of a product security programme we set up and run with you:
Security Requirements
Secure-by-design requirements written for your product, so engineers know the security bar before they build a feature.
Release Gates
Agreed checks a release must pass before it ships, scaled to the risk of the change rather than applied to everything.
SBOM and Components
A software bill of materials for each product, with known vulnerabilities and licence risks in third-party code tracked over time.
Vulnerability Handling
A published disclosure policy and a product security incident response team (PSIRT) process for triage, fixes and customer advisories.
Customer Assurance
Reusable answers, policies and evidence for security questionnaires, due diligence and SOC 2 readiness.
Regulatory Readiness
Your products checked against the UK PSTI Act and the EU Cyber Resilience Act, with the gaps listed in priority order.
How we set up your product security programme
We fit the programme around how your teams already plan, build and release, so it adds as little friction as possible.
- Scope — We list your products, who buys them, where they are sold and which regulations and customer demands apply.
- Baseline — We review your current design, release, dependency and incident practices against that scope and agree the gaps that matter most.
- Build — Requirements, release gates, SBOM tooling and the disclosure and PSIRT process are put in place with your engineering leads.
- Run — We review new features and releases with your team, keep the SBOM current and help handle reported vulnerabilities as they arrive.
What you have at the end
Product security should leave you with documents and processes your team owns, not a report that sits in a folder. These are the artefacts most buyers and regulators ask to see.
Disclosure Policy
A public route for researchers and customers to report security issues
Current SBOMs
Component lists you can share with buyers on request
Answer Library
Approved responses for security questionnaires and due diligence
Application security or product security?
Application security
Secures your application code: secure coding, testing, API security and authentication controls.
Start here when the main risk sits in live code.
Product security
Secures how the product is designed, released and supported: requirements, release gates, SBOMs, disclosure and customer assurance.
Choose this when customers, regulators or your supply chain start asking for proof.
Evidence for buyers, audits and regulators
Product security produces evidence as a by-product of the work: release gate records, SBOM history, vulnerability tickets with fix times, and customer advisories. That evidence supports a SOC 2 readiness programme, an ISO 27001 certification and the supplier reviews your enterprise customers run.
For connected consumer products sold in the UK, the PSTI Act already requires no universal default passwords, a published way to report security issues and a stated security update period. If you sell into the EU, the CRA adds vulnerability reporting duties from September 2026 and wider obligations from December 2027. Our compliance support team can help you keep that evidence organised for each audience.
Services that work alongside
Product security sets the programme; other services do specific jobs inside it. Threat modelling maps how a new feature could be attacked at design stage, and application security tests and reviews the code itself. CI/CD security hardens the pipelines that build and ship your releases.
Before a major release or a large customer deal, penetration testing gives you independent findings to share. If your product includes AI features, see AI and ML security. Investors reviewing a software business can use our technical due diligence service.
Frequently asked questions
Make security part of what you ship
Tell us what you build, who buys it and which questionnaires or regulations are landing on your desk. You get a clear view of the gaps and the order to close them in.