Security management
Who owns product cybersecurity, who is trained, how the process is checked and improved.
What we draftProduct cybersecurity policyRoles and training record
Product cybersecurity
IEC 62443-4-1 SDLC Certification
A secure development lifecycle built from how you already work, written down once, and certified.
Best forOEMs whose customers ask for IEC 62443-4-1, or who want one process that also carries the CRA evidence. ISASecure SDLA, TÜV or exida.
Service overview
Your process, not a template library
IEC 62443-4-1 asks for a secure development lifecycle across eight practices, from security management and requirements to updates and guidelines. It does not ask you to become a different company. Most teams already do half of it; they have just never written it down in a form an auditor can follow.
We start with how you build today and keep it. Ownership of product cybersecurity is assigned to one person on your side, security gates go into the release process you already run, and every policy, procedure, guide and template is drafted from your ways of working. No generic policy templates, ever: each document is written for your team, your tools and your products.
We ask you to do the bare minimum the standard needs, and we make sure it holds up against the strictest audit. Members of our team actively contribute to ISA99, the committee that writes the standard, so we know what each requirement is for and what evidence an auditor will accept.
What we set up
- Ownership of product cybersecurity assigned on your side, with the authority to sign off
- Security gates inside your existing release process, not a parallel one
- Policies, procedures, guides and templates for all eight practices, drafted from your ways of working
- Threat modelling and security requirements that fit your design reviews
- Secure implementation and verification: coding rules, static analysis, fuzzing and penetration tests sized to the product
- Vulnerability handling, security updates and end-of-support rules that also serve the CRA
- Maturity level set per practice: ML 2 where a defined process is enough, ML 3 for what goes into a product heading for IEC 62443-4-2 certification
- Evidence collected from one pilot release, so the audit sees a process that runs
- Audit preparation and support on the day
IEC 62443-4-1
Eight practices, your documents
Policies say what, guides say how, templates capture the evidence. One set across the eight practices, each document drafted from how your team already works. No generic templates.
PolicyGuideTemplate
Security requirements
Threat model, security context and the requirements each product must meet.
What we draftThreat modelling guideSecurity requirements
Secure by design
Defence in depth, a known attack surface and a design review that looks for both.
What we draftSecure design guideDesign review checklist
Secure implementation
Coding rules and static analysis applied to every change.
What we draftSecure coding rulesCode review record
Verification and validation
Tests for the requirements, the threat mitigations, known vulnerabilities and penetration.
What we draftSecurity test guideTest plan and report
Security issue management
Receiving, triaging, fixing and disclosing vulnerabilities.
What we draftVulnerability disclosure policyVulnerability handling procedure
Security update management
Updates that are tested, signed and delivered in time, with the user told what changed.
What we draftSecurity update procedureRelease checklist
Security guidelines
Hardening and secure configuration guidance for the people who deploy the product.
What we draftSecure deployment guideHardening checklist
Maturity levels
Each practice is graded by maturity level, and the certificate states the level reached. For an IEC 62443-4-2 component certificate, ML 3 is required, but only for what goes into the product being certified: the written process must have been followed for the features going into that product, and the evidence must show it. Not for everything you make. We set the target level per practice, so you do not raise the whole organisation to ML 3 for one product.
ML 1Initial: done ad hoc, little written down
ML 2Managed: written down, people trained, repeatable
ML 3Practiced: the written process has been followed at least once, on a product, a component or a feature, and the evidence shows it
ML 4Improving: measured and improved over time
Gap assessment output
The traffic light report
The first weeks end with a practice-by-practice map in three colours: what you already do, what you do but have not written down, and what is missing.
Green
Keep doing
Already done and written down. Goes into the audit file as it is.
Amber
Tune up
Done but not written down, or written down but not followed. A document or a habit to fix.
Red
Start now
Not done. A practice to set up before the pilot release.
Our approach
Engagement methodology
The steps of the engagement, built around how your team already designs, builds and releases the product.
See how you build today
Interviews with your engineers and product owners, and a read of what you already have: design reviews, test plans, release checklists, ticket flow. We map each to the eight practices and mark what exists, what exists but is not written down, and what is missing.
OutputPractice-by-practice gap map
Assign ownership and set the gates
Ownership of product cybersecurity is assigned to one person on your side, usually the security or system architect. We agree where the security gates sit in your current release process and what each gate needs to see. No new process runs beside the old one.
OutputOwnership and gate definition
Draft the documents from your ways of working
Policies, procedures, guides and templates for every practice, written from what your team does, in the tools they use. We do not start from a template library. If a requirement can be met by what you already do, the document says so and we move on.
OutputDocument set for eight practices
Run it on one release
The process runs on one product or one release with us beside the team. The evidence that comes out, threat model, requirements, test reports, update records, is the evidence the auditor will see. What does not work in practice is changed before the audit, not after. This is what takes a practice from ML 2, written down, to ML 3, practiced with evidence.
OutputPilot release evidence pack
Certification audit
We prepare the audit file, rehearse the interviews and sit with you on the day, whether the scheme is ISASecure SDLA, TÜV or exida. Findings are closed with the same people who wrote the documents.
OutputCertificate
Common questions
Frequently asked questions
Talk to RelyBlue
Ready to discuss IEC 62443-4-1 SDLC Certification?
An honest conversation about your product and the path to CRA compliance or IEC 62443 certification. No sales pressure, no fear tactics.
- You talk to a senior advisor, never a salesperson