stratops.Cyber capabilities as a service
Domain · Security by design

Security decided at design time, not discovered in production.

We build security into your projects from the start: explicit requirements, threat modelling, architecture reviews and acceptance criteria checkable before release.

Describe your needAll domains
Situations

You are in the right place if…

  • Your applications’ flaws are found at the penetration test, just before release.
  • Your product teams start projects without written security requirements.
  • Nobody can say which threats a new architecture must counter.
  • You place a digital product on the market and must document its risk assessment.
  • Your CI/CD pipeline ships fast, but nothing in it checks security.
Our conviction

A flaw avoided at design time costs less than a flaw fixed in production.

Fixing a design flaw once the product has shipped often means reworking the architecture, migrating data, notifying clients. At design time, the same decision fits in one line of requirement.

So we build security into your teams’ existing rituals: a requirement in the ticket, a threat in the architecture diagram, a criterion in the definition of done, a control in the delivery pipeline.

Our approach

From requirement to acceptance criterion.

Light practices, built into your development cycle, rather than a parallel process.

  1. 01State the requirementsFor each project or feature: data processed, exposure, obligations, security requirements.

    You getWritten security requirements

  2. 02Model the threatsA short workshop with the team: what can go wrong, and what prevents it.

    You getAn up-to-date threat model

  3. 03Review the architectureAuthentication, segregation, encryption, logging, dependencies: reviewed before development.

    You getDocumented architecture decisions

  4. 04Set acceptanceCheckable criteria, tested in the delivery pipeline before release.

    You getAcceptance criteria and their controls

What the texts say

What the texts expect of design.

Several texts make security a design requirement, no longer just an operating one.

  • CRACRA art. 13(1) · CRA art. 13(2)

    The manufacturer of a product with digital elements designs and develops it in accordance with the essential cybersecurity requirements, and assesses its cybersecurity risks to take them into account from planning to maintenance.12

  • DORA · RTSRTS 2024/1774 art. 16(1) · RTS 2024/1774 art. 16(1), point (b) (ii)

    Financial entities adopt a policy governing the acquisition, development and maintenance of ICT systems, which identifies security requirements and has them approved by the business function and the asset owner.34

  • NIS 2NIS 2 art. 21(2), point (e)

    The directive lists security in the acquisition, development and maintenance of systems among the measures Member States must require of entities.5

  • GDPR · CNIL guideRGPD art. 25(1) · Guide CNIL sécurité, fiche 11, F11-PE-01

    The controller implements data protection by design; the CNIL recommends building security requirements into it, through choices of architecture, features and technologies.67

The texts do not apply to every organisation: whether they apply depends on your status, your sector, your size and your contracts. Have it confirmed by your legal counsel or a specialised lawyer.

Our engagement

The same topic, at three levels of engagement.

You choose the level; the scope and deliverables are set by contract.

Level 01

Monitor

At agreed intervals, we check that projects go through the planned security steps and that delivery pipeline controls run.

Deliverables
  • Tracking of projects and their security steps
  • Check of acceptance criteria in CI/CD
  • Dashboard of gaps
Level 02

Advise

We run threat modelling workshops, review architectures and write the requirements.

Deliverables
  • Security requirements per project
  • Threat models and architecture reviews
  • Product risk assessment
Level 03

Drive

We embed the practices in your teams and track their adoption, without making the changes in your systems.

Deliverables
  • Integration into the team’s rituals and tools
  • Tracking of decisions and gaps
  • Evidence file for your clients and auditors
Accelerators

What we bring from day one.

Requirements catalogue

Reusable security requirements by project type, linked to the texts they serve.

Threat workshop format

A one-hour workshop, with its materials, to model a feature’s threats with the team.

Delivery pipeline controls

Checks to plug into your CI/CD so acceptance criteria are tested at every release.

Frequently asked questions

Before we start.

Does this slow our teams down?

Little, if the practices fit into existing rituals: a requirement in the ticket, a short workshop for sensitive features, an automatic control in the pipeline. The time comes back in fixes avoided.

Must every feature’s threats be modelled?

No: only features that touch sensitive data, authentication, payments or exposure. We help your teams spot them.

Does the CRA require a risk assessment?

Yes, for a manufacturer of a product with digital elements: it must be carried out and taken into account from planning to maintenance. Have the CRA’s applicability confirmed by your legal counsel or lawyer.2

Do you work with our agile methods?

Yes. We fit into your rituals (refinement, review, definition of done) rather than adding a process alongside.

Start with your next project.

Describe the project and how you work. We come back to you with a support proposal.

Describe your need
Sources

The excerpts quoted.

Exact text, in its original language, from the frameworks extracted from the official text.

Show the 7 excerpts quoted
  1. 1CRA art. 13(1)32024R2847-a13-p1
    When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)
    Version
    CELEX 32024R2847 — ELI reg/2024/2847
    Official text
  2. 2CRA art. 13(2)32024R2847-a13-p2
    For the purpose of complying with paragraph 1, manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)
    Version
    CELEX 32024R2847 — ELI reg/2024/2847
    Official text
  3. 3RTS 2024/1774 art. 16(1)32024R1774-a16-p1
    As part of the safeguards to preserve the availability, authenticity, integrity, and confidentiality of data, financial entities shall develop, document and implement a policy governing the acquisition, development, and maintenance of ICT systems. That policy shall:
    Normative force
    directly applicable EU law (delegated regulation — RTS, level 2)
    Source
    Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework
    Version
    CELEX 32024R1774 — ELI reg_del/2024/1774
    Official text
  4. 4RTS 2024/1774 art. 16(1), point (b) (ii)32024R1774-a16-p1-4
    requirements relating to the acquisition, development, and maintenance of ICT systems, with a particular focus on ICT security requirements and on their approval by the relevant business function and ICT asset owner in accordance with the financial entity’s internal governance arrangements;
    Normative force
    directly applicable EU law (delegated regulation — RTS, level 2)
    Source
    Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework
    Version
    CELEX 32024R1774 — ELI reg_del/2024/1774
    Official text
  5. 5NIS 2 art. 21(2), point (e)32022L2555-a21-p2-5
    security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
    Normative force
    EU law to be transposed (directive): not directly applicable, requires national transposition
    Source
    Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive)
    Version
    CELEX 32022L2555 — ELI dir/2022/2555
    Official text
  6. 6RGPD art. 25(1)32016R0679-a25-p1
    Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
    Version
    CELEX 32016R0679 — ELI reg/2016/679
    Official text
  7. 7Guide CNIL sécurité, fiche 11, F11-PE-01F11-PE-01
    Intégrer la protection des données, y compris ses exigences en termes de sécurité des données, dès la conception de l’application ou du service. Ces exigences peuvent se traduire par divers choix d’architecture (décentralisée ou centralisée), de fonctionnalités (ex. : anonymisation à bref délai, minimisation des données), de technologies (ex. : chiffrement des communications), etc.
    Normative force
    recommendation (soft law)
    Source
    Guide pratique RGPD — Sécurité des données personnelles
    Version
    2024 (mise à jour 2026)
    Official text