Adapted from the Polish article, originally published on 19 August 2026 and updated on 18 September 2026. The English version was published on 01 October 2026.
“The system will be developed in accordance with security best practice.”
That sentence looks reassuring until the customer treats missing multi-factor authentication as a defect and the development supplier treats it as a new feature. A pre-launch audit may also uncover excessive permissions, missing logs and vulnerable dependencies that never appeared in the scope or backlog.
Secure by design needs to reach architecture and code, but a commercial project also needs defined scope, acceptance criteria, change control and evidence. This article considers the contract between a customer and a software development supplier. ENISA guidance can help frame the discussion; it does not itself decide every contractual obligation.
On 30 July 2026, ENISA published its Secure by Design and Default Playbook. For smaller organisations, it offers practical steps that can be connected to the project plan and allocation of work.
What you will learn
- How secure by design and secure by default affect a development project.
- Why a general security clause does not settle scope or price.
- How a baseline connects requirements, acceptance and evidence.
- How to distinguish a defect from an added requirement.
- What release gates, configuration and dependency processes need to cover.
In brief
- Secure by design considers threats throughout the product lifecycle.
- Secure by default concerns the initial configuration delivered to users.
- Agree minimum controls, owners, acceptance criteria and evidence.
- A requirement agreed before work begins may be in scope; a new expectation may require a change in budget or timing.
- A release gate should identify what blocks a release and who can approve a documented exception.
What do secure by design and secure by default mean?
Secure by design brings security into product requirements and architecture. The team considers data, user roles, access points and possible abuse before the final deployment review.
Secure by default means shipping the product with suitably secure initial settings. Unnecessary services, shared passwords or excessive permissions should not be left enabled merely because that made testing easier.
ENISA’s repository contains 22 playbooks covering the product lifecycle. Their structure connects principles to actions, evidence and a release gate. The topics include trust boundaries, least privilege, logging, secure coding, configuration, incident handling and supply-chain controls.
The playbooks are a practical starting point. Adapt them to the product, its users, risks and applicable requirements. Copying every checklist into a contract would not establish who can perform the work or which controls the project needs.
Why does a general security clause leave room for dispute?
The customer may expect administrator MFA, encryption, separated roles, security logs, dependency scanning, security testing and vulnerability handling. The supplier may have priced the stated business features while expecting the customer to arrange security architecture, testing and maintenance separately.
Either allocation may be workable if it is explicit. A general best-practice promise leaves the parties to resolve their different expectations at acceptance, during an audit or after an incident.
A security clause can set a direction. It still needs to explain whether MFA was included in the price and which vulnerabilities block acceptance.
Define the security baseline
A baseline is the agreed minimum set of security requirements for the product. It need not be a long standard, but the team must be able to build against it and the customer must be able to verify it.
Start with the product’s use, data, risk assessment, enterprise requirements, deployment environment and applicable obligations. A useful requirement also identifies evidence, for example:
- Administrator access: MFA and individual accounts, verified through a configuration test.
- Permissions: least-privilege roles, verified through test scenarios.
- Dependencies: no known vulnerabilities above the agreed threshold, supported by a scan of the relevant release.
- Logging: specified events and a tested alert.
- Secrets: repository scanning and a process for handling findings.
- Production configuration: an agreed configuration profile and handover record.
- Updates: an owner and process for critical vulnerabilities.
Not every product needs every control. A requirement important to the customer should nevertheless be visible to the supplier, with the relevant assumptions and exclusions.
Who prepares the threat model?
Threat modelling describes what needs protection, who could compromise it and through which paths. Both parties hold information needed to make it useful.
The customer knows the business process, users, data, integrations and consequences of disruption. It should supply that context, including sector requirements and the intended environment.
The supplier knows the architecture and components. Its work may include identifying trust boundaries and attack surfaces, describing abuse scenarios, proposing controls and updating the model after significant architecture changes.
Name the person authorised to accept residual risk. A developer can explain a technical consequence; the business decision to leave a risk open belongs to someone with the appropriate authority. Record that decision and its conditions.
Is a missing control a defect or a scope change?
A control required by the agreed specification, baseline or acceptance criteria may be part of the original scope. A later request that changes architecture, integration or effort may be additional work. The contract, relevant standards and applicable legal duties still need to be assessed in the particular project.
The agreement should distinguish:
- The mandatory baseline.
- Risks discovered during development.
- New customer requirements.
- Changes in law or an expressly adopted standard.
- Vulnerabilities in external libraries.
- Defects in supplier code.
- Improvements not previously agreed.
Use a short security change process: describe the risk, impact, proposed response, cost and timing. The authorised owner decides on the fix or a temporary exception, and the decision becomes part of the project record. Do not let an exception silently turn into a permanent assumption.
What evidence should acceptance require?
Functional tests showing that a user can log in or download a report do not establish whether access is restricted properly or abuse is logged. Security needs its own agreed test scenarios.
Acceptance may require role-access tests, absence of default shared credentials, appropriate encryption, rotation of secrets, critical-event logging, safe failure behaviour and delivery of architecture or dependency information. The parties can also agree a vulnerability threshold and assessment method.
Specify the tested version, environment, tool and timing. A scan of an older build is weak evidence for the current release. Evidence can be proportionate: a test result, configuration extract, scan report, role matrix or recorded automated check may be enough for a particular requirement.
The point is to make the result verifiable, rather than demand a lengthy report for every control.
What should a release gate do?
A release gate is a condition that must be satisfied before production deployment, unless an authorised person approves an exception. Make it measurable and proportionate so that it does not become an unlimited right to delay every release.
Possible gates concern known vulnerabilities above a threshold, an outdated threat model, incomplete access-control tests, configuration outside the baseline or missing evidence.
An approved exception should identify its owner, reasons, expiry or review date and remediation plan. A chat message saying “go ahead” does not provide those details. Keep the approval where both parties can reconstruct the decision later.
Who owns production configuration?
Agree who prepares the secure configuration, who deploys it and who controls subsequent changes. Record the state handed over by the supplier.
After delivery, the customer might disable MFA, expose a service publicly, widen permissions, reduce logging to save money or postpone updates. Without a handover and change record, an incident can turn into a dispute about whose configuration caused the problem.
The EU Cyber Resilience Act supports lifecycle security and secure defaults for products within its scope. It does not automatically make every development supplier the manufacturer. Scope and role need separate assessment, and the regulation’s requirements have phased application dates. Our CRA security-update guide explains that distinction.
Dependencies need an owner after delivery
Libraries, packages, container images and external services can affect product security. Set rules for their selection, recording, vulnerability monitoring and updating after deployment.
A Software Bill of Materials, or SBOM, records the product’s components. ENISA’s SBOM Adoption State of Play - 2026 examines how organisations approach these records. An inventory supports the process, but it does not itself fix a vulnerable component.
Agree who monitors disclosures, assesses whether the product is affected, prepares a patch or workaround, communicates with the customer and continues the work during the support period. When an upstream fix is unavailable, the process still needs an assessment and mitigating steps.
That work should connect with the SaaS SLA. Availability measurement, security remediation and maintenance windows are related promises with different purposes.
A hypothetical case: the audit just before launch
This example is illustrative, not a client history. A supplier builds a SaaS ticketing platform. The specification includes user roles, a CRM integration and an administrator panel. The contract promises security best practice.
A week before launch, the customer commissions a security test. It finds no administrator MFA, excessive employee permissions, no alert after repeated failed logins, a library with a known high-severity vulnerability and logs containing inappropriate data.
The customer refuses acceptance. The supplier treats MFA and the alert system as additional scope. Updating the library affects another component, and the project has no agreed dependency policy.
A clearer project process would have included:
- A baseline approved before coding and a threat model after architecture design.
- A role matrix in the specification.
- Dependency scanning before releases.
- Security testing before the final project stage.
- Release gates for critical and high-severity findings.
- A procedure for deciding whether each finding is a defect, change or exception.
These steps do not guarantee error-free software. They make it less likely that the first substantive security discussion happens immediately before launch.
What should the contract and its schedules answer?
- Which baseline, standards and policies apply?
- Who supplies risk information and maintains the threat model?
- What are the security acceptance criteria and required evidence?
- Which findings block production, and who may accept an exception?
- How are defects distinguished from changes in scope?
- Who owns dependencies, configuration and vulnerability monitoring?
- When does implementation end and maintenance begin?
- What configuration and technical records are handed over?
ENISA’s SME Cyber Resilience Maturity Assessment Model can help identify organisational gaps. It does not replace the requirements agreed for a specific project.
Security work needs an owner, evidence and a deadline. Connect those with scope, price and acceptance while the team can still make design choices.
For help translating technical requirements into a Polish-law development or maintenance contract, see our IT and software legal services or contact us about the project. Where a regulated customer sends additional supply-chain requirements, our KSC and NIS2 supplier-contract guide covers the allocation of duties.