Secure-by-Demand Software Procurement in 2026

It is Tuesday morning in early 2026, and Maria, the CISO of a rapidly expanding European payments company, is presenting to the board. The final agenda item should be routine: approval for a new AI-powered fraud detection platform. The vendor has an impressive demo, a limited-time discount, a one-page security overview and a standard contract.

Then the questions start.

The CEO asks, “How do we know this platform is secure? Our financial services clients are asking for DORA compliance evidence, and this supplier becomes part of our critical infrastructure.”

Legal asks whether the Data Processing Agreement is ready, where EU customer data will be processed and whether sub-processors are disclosed. The operational resilience lead asks about exit planning, backup exports and continuity for critical functions. The product security engineer asks for vulnerability disclosure, patching evidence and an SBOM or equivalent component transparency statement. Procurement asks the question that makes supplier risk expensive: “Can we approve now and collect the documents after signature?”

That is the moment when modern software procurement either becomes a control or becomes a future incident report.

In 2026, secure software procurement cannot rely on post-contract goodwill. NIS2 supply chain security, DORA ICT third-party risk, GDPR processor accountability and Cyber Resilience Act product security expectations have moved supplier assurance to the procurement decision point. Buyers need secure-by-demand software procurement, where the customer defines the security evidence, contract clauses, onboarding gates and operational responsibilities before purchase.

For Clarysec clients, the answer is not another spreadsheet that dies in email. It is an ISO/IEC 27001:2022-aligned procurement control system, mapped through Clarysec policies, the Zenith Blueprint: An Auditor’s 30-Step Roadmap and Zenith Controls, so every software or SaaS purchase has a defensible trail from business need to supplier risk decision.

Secure-by-demand is the new software procurement control

Secure-by-design is usually discussed from the vendor side. Secure-by-demand is the buyer-side discipline: the organization refuses to buy software unless the vendor can demonstrate that security, privacy, resilience, vulnerability handling and auditability are built into the offer.

This changes the buying conversation. Instead of asking, “Do you have security?”, procurement asks sharper questions:

• What data will you process, where and under what legal role?
• Which business function will depend on you, and how critical is it?
• What evidence proves your controls operate, not just that they are documented?
• What incident notification timelines will you commit to?
• What vulnerability disclosure, patching, SBOM or VEX evidence can you provide?
• Which subcontractors or sub-processors will touch our data or service?
• Can we audit, inspect or request evidence during the contract term?
• What happens at termination, migration, breach, insolvency or regulatory inquiry?

ISO/IEC 27001:2022 gives the management-system backbone for this shift. Clause 4 requires the organization to understand context, interested parties and ISMS scope, including external regulatory and supplier requirements. Clause 5 turns supplier risk into a leadership and governance responsibility. Clause 6 requires risk assessment, risk treatment, control selection, a Statement of Applicability and residual risk decisions. Clause 8 requires controlled operation of processes, including externally provided processes. Clause 9 requires monitoring, internal audit and management review.

That means software procurement is not just a commercial workflow. It becomes an operated and auditable ISMS process. Regulators and auditors increasingly ask why an organization accepted a supplier before it understood the risk. Secure-by-demand procurement gives a clear answer: the risk was assessed, treated, contracted and assigned before dependency was created.

Why NIS2, DORA, GDPR and CRA converge at supplier selection

Maria’s board is asking the right questions because a single software supplier can trigger several obligations at once.

NIS2 applies by sector, size and criticality, with Annex I and Annex II bringing many digital, financial, infrastructure, managed service and cloud-dependent organizations into scope. Article 21 requires appropriate and proportionate technical, operational and organizational measures, including supply chain security, secure acquisition, secure development and maintenance, vulnerability handling, access control, asset management, continuity, incident handling and control effectiveness assessment. Article 21(3) specifically requires attention to direct-supplier vulnerabilities and suppliers’ cybersecurity practices. Article 23 creates staged significant incident reporting expectations, including early warning within 24 hours and notification within 72 hours.

DORA applies from 17 January 2025 to in-scope financial entities. It creates uniform requirements for ICT risk management, ICT-related incident reporting, digital operational resilience testing and ICT third-party risk management. DORA is especially prescriptive for procurement. Financial entities need ICT third-party risk strategies, registers of ICT-service arrangements, due diligence, concentration-risk analysis, written contracts with security and resilience provisions, audit and access rights, cooperation duties, termination rights and exit plans. Articles 28 and 30 are central to ICT third-party risk and contractual controls, while Articles 17 to 23 shape incident management and reporting.

GDPR adds the processor accountability gate. Articles 5, 28, 32, 33 and 34 require accountability, processor contracts, appropriate security, breach notification cooperation and data-subject impact handling. A SaaS supplier that processes personal data is not just a vendor. It becomes part of the controller’s compliance posture. The DPA, technical and organizational measures, sub-processor list, transfer safeguards, retention rules and deletion obligations must be understood before processing begins.

CRA expectations add product assurance. Even where the buyer is not the manufacturer, procurement teams should demand evidence of secure development, vulnerability handling, product support, security updates, coordinated vulnerability disclosure and component transparency, such as an SBOM or equivalent statement. These requirements belong in RFPs, security annexes and acceptance gates.

The common theme is simple: the buying organization must know what it is buying, what risk it imports and what evidence it can produce when regulators, customers or auditors ask.

The ISO 27001 control spine for supplier assurance

The most effective secure-by-demand procurement model is not regulation-by-regulation. It is control-first. Clarysec uses ISO/IEC 27001:2022 as the ISMS spine, supported by ISO/IEC 27002:2022 control guidance and cross-compliance mapping in Zenith Controls.

In Zenith Controls, supplier assurance is anchored around ISO/IEC 27002:2022 controls 5.19, 5.20 and 5.21. These are not isolated checklist items. They form a procurement lifecycle.

Zenith Controls maps these ISO controls across regulatory and audit expectations. It does not create separate proprietary controls called Zenith Controls. It helps teams understand how ISO/IEC 27002:2022 controls support NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-oriented assurance.

The supporting control network matters too. Supplier assurance connects to asset management, access control, cloud security, vulnerability management, logging, incident management, ICT readiness for business continuity, secure development, application security, configuration management, backup, redundancy, legal compliance, privacy, change management and independent review. Procurement coordinates the process, but risk ownership must include the business owner, information security, legal, privacy, IT, finance and the service owner.

Clarysec policy gates before signature

Clarysec’s policy model deliberately moves supplier assurance upstream. The strongest language appears where it belongs: before agreements are signed, before cloud subscriptions are activated and before data is shared.

The SME version of Clarysec’s Third-Party and Supplier Security Policy states:

Assess and document supplier risks before agreements are signed or access is granted.

This comes from section “Objectives”, policy clause 3.3. The clause is short because the control intent is non-negotiable: no risk assessment, no contract, no access.

For enterprise environments, Clarysec’s Third party and supplier security policy reinforces the pre-contract gate:

All new suppliers must undergo a documented security assessment before contract execution.

This comes from section “Policy Implementation Requirements”, policy clause 6.1.1. The same policy also identifies “Rights to audit, inspect, and request security evidence” in section “Governance Requirements”, policy clause 5.3.4.

For cloud and SaaS buying, the SME Cloud Usage Policy adds a practical approval gate:

All use of cloud services must be reviewed and approved by the General Manager (GM) before implementation or subscription.

This comes from section “Governance Requirements”, policy clause 5.1. In a small organization, that approval may be the equivalent of a cloud governance board. In an enterprise, it becomes a workflow across procurement, security, privacy and architecture. The enterprise Cloud Usage Policy also supports contractual cloud requirements, including enforceable provisions in CSP contracts.

For software acquisition, the enterprise Application Security Requirements Policy is explicit:

Software acquisition or outsourcing arrangements must include security requirements in RFPs, contracts, and SLAs, including provisions for vulnerability remediation timelines and third-party audit rights.

This comes from section “Governance Requirements”, policy clause 5.4. Notice the ordering: RFPs, contracts and SLAs. Security appears at the market engagement stage, not as a post-award attachment.

For GDPR-driven procurement, Clarysec’s SME Legal and Regulatory Compliance Policy requires:

Data Processing Agreement (DPA) clauses or equivalent contractual terms must be agreed before any personal or sensitive data is shared.

This comes from section “Policy Implementation Requirements”, policy clause 6.3.2. This prevents one of the most common SaaS onboarding failures: uploading personal data into a tool before processor terms, breach obligations and sub-processor conditions are agreed.

For vendor application security, the SME Application Security Requirements Policy requires procurement to:

specify obligations for vulnerability disclosure, response times, and patching.

This is from section “Governance Requirements”, policy clause 5.3.2. It also states:

The GM must request Documentation or certifications (e.g., SOC 2, ISO 27001, security test reports) as evidence of vendor compliance, where applicable.

This comes from section “Policy Implementation Requirements”, policy clause 6.3.2. The key word is evidence. Secure-by-demand procurement is not based on trust statements. It is based on reviewable artefacts.

The Zenith Blueprint procurement gate

The Zenith Blueprint treats supplier security as an operated control, not a procurement slogan. In the Controls in Action phase, Step 23 covers Organizational controls 5.19 to 5.37, including information security in supplier relationships.

The Blueprint explains:

It starts with supplier classification. Not all suppliers carry the same risk. A cleaning service may have physical access to offices, but not to networks. A penetration testing firm or cloud hosting provider, on the other hand, may have deep technical access to the very heart of your infrastructure. Classification should consider whether the supplier handles or processes your information directly, whether they provide infrastructure or platforms upon which you operate, whether they manage or maintain systems on your behalf, and whether their compromise could impact your confidentiality, integrity, or availability objectives.

For control 5.20, the Blueprint is direct:

Key areas typically addressed in supplier agreements include confidentiality obligations; access control responsibilities; technical and organizational measures for data protection, encryption, secure transmission, backup, and availability commitments; incident reporting timelines and protocols; right to audit, including frequency, scope, and access to relevant evidence; subcontractor controls; and end-of-contract provisions such as data return or destruction, asset recovery, and account deactivation.

It concludes that control 5.20 is “your last line of leverage” and “belongs at the procurement gate.” Once the contract is signed, leverage drops. Before signature, evidence and obligations can be made conditions of purchase.

For outsourced development, the Controls in Action phase, Step 21, control 8.30, adds another procurement requirement. The Blueprint states:

At the core of this control is the principle that security must be a contractual requirement, not a verbal expectation.

Outsourced teams should meet the same secure development standards as internal teams, including static analysis, peer review, encryption, MFA to repositories and visibility into code, architecture decisions, vulnerabilities, change requests, CI/CD logs and scan results.

Build a secure-by-demand RFP gate in one afternoon

Assume your organization wants a customer analytics platform. It will ingest customer identifiers, behavioral events, support metadata and transaction references. The business owner wants fast approval. The security team has one week.

Start with a procurement gate record using the Third party and supplier security policy, Application Security Requirements Policy, Cloud Usage Policy, Legal and Regulatory Compliance Policy and Step 23 of the Zenith Blueprint as source documents.

Attach a secure-by-demand questionnaire to the RFP. Avoid generic questions like “Do you encrypt data?” Ask evidence-driven questions:

1. Provide your current independent security assurance report, certificate or equivalent control evidence.
2. Identify hosting locations, data residency options, backup locations and support access locations.
3. Provide the DPA, sub-processor list and notice process for sub-processor changes.
4. Confirm incident notification timelines, including 24-hour early warning support where NIS2 workflows may be triggered and phased reporting support for DORA-regulated customers.
5. Provide vulnerability disclosure policy, patch SLAs by severity and evidence of recent vulnerability remediation governance.
6. Provide product security evidence, such as secure development lifecycle description, penetration test summary, SBOM or component transparency statement and security update support period.
7. Confirm MFA, least privilege, logging, administrative access monitoring and customer audit or evidence request rights.
8. Describe export, deletion, return, termination support and transition assistance.
9. List material subcontractors and ICT dependencies supporting the service.
10. Confirm whether customer data is used for training, analytics, product improvement or AI model development, and identify the lawful basis or processor instruction model.

Then score the vendor before negotiation.

Finally, update the risk register and Statement of Applicability. The risk treatment record should show why ISO/IEC 27002:2022 controls 5.19, 5.20 and 5.21 apply, which contractual and technical requirements were selected, who owns residual risk and what monitoring cadence applies. If the business wants to proceed despite gaps, use a formal risk acceptance record with an expiry date, compensating controls and executive approval.

Contract clauses that convert regulation into enforceable obligations

Security expectations must become contractual commitments. A certificate may be useful, but it rarely answers every question about your exact service, data location, subcontractors, support model, incident commitments or exit rights.

This table is the practical bridge between legal obligations and procurement work. It also helps legal, security and procurement negotiate from the same control baseline.

Cross-compliance mapping: one supplier file, many obligations

The advantage of using ISO/IEC 27001:2022 as the backbone is that one supplier assurance file can support multiple regulatory conversations.

NIST CSF 2.0 is useful as a communication layer. Its GOVERN function emphasizes legal, regulatory, contractual, privacy and dependency awareness. Its GV.SC supply-chain outcomes require supply chain risk management processes, supplier roles, supplier prioritization by criticality, contractual requirements, due diligence, monitoring, incident planning and termination planning.

That maps cleanly to Step 23 of the Zenith Blueprint and ISO/IEC 27002:2022 controls 5.19 to 5.21 as mapped in Zenith Controls. It also gives boards a language they understand: current state, target state, gap, risk, action, owner and date.

What auditors will ask

A strong secure-by-demand procurement process should survive different audit lenses.

An ISO/IEC 27001:2022 auditor will start with ISMS context and scope. They will ask whether supplier interfaces and dependencies are included, whether interested-party requirements include NIS2, DORA, GDPR and customer contracts, and whether supplier risks are assessed consistently under the risk methodology. They will follow the trail into risk treatment, Statement of Applicability, supplier controls, operational evidence, internal audit and management review.

A DORA reviewer will focus on ICT-supported business functions, critical or important functions, third-party dependency records, contractual clauses, audit and access rights, incident cooperation, resilience testing, exit strategies and concentration risk. If a SaaS supports a critical or important function, a lightweight vendor questionnaire will not be enough.

A NIS2 authority will ask how the organization assessed supplier cybersecurity practices, direct-supplier vulnerabilities, incident notification support, continuity dependencies and secure acquisition decisions. They will test whether supplier assurance supports the organization’s own Article 21 and Article 23 obligations.

A GDPR reviewer will ask whether controller and processor roles were understood before processing started, whether a DPA or equivalent terms were agreed before data was shared, whether sub-processors were disclosed, whether security measures were appropriate, whether breach cooperation is contractual and whether data return or deletion is enforceable.

A COBIT 2019 or ISACA-style auditor will focus on governance and accountability: who approved the supplier, which risk was accepted, whether policy requirements were followed, whether exceptions are tracked and whether benefits, risk and resources were balanced.

Your evidence pack should include supplier classification, business owner approval, risk assessment, RFP security requirements, vendor responses, DPA, security annex, SLA, audit rights, sub-processor register, vulnerability commitments, incident clauses, cloud location evidence, logging and encryption evidence, exit terms, reassessment records, exceptions and Statement of Applicability mapping.

Common failure patterns in software buying

The first failure is treating procurement as a commercial workflow and security as a technical workflow. By the time security receives the contract, the business has already committed psychologically, the implementation date is announced and negotiation leverage is weak.

The second failure is evidence substitution. A vendor provides a certificate, and the buyer assumes it answers every question. Certification can help, but it may not cover the exact product, hosting region, support model, subcontractor chain, incident obligations, AI data use or exit requirements.

The third failure is missing downstream risk. A SaaS vendor may rely on cloud hosting, analytics tools, support platforms, offshore development teams, AI model providers and payment processors. ISO/IEC 27002:2022 control 5.21 requires attention to the ICT supply chain behind the direct supplier. Under DORA, this connects to subcontracting and concentration risk. Under GDPR, it connects to sub-processors. Under NIS2, it connects to direct-supplier vulnerabilities and supplier cybersecurity practices.

The fourth failure is weak incident language. A contract that says “supplier will notify customer promptly” may not support NIS2 early warning, DORA phased reporting, customer communications or internal escalation. Incident clauses need timeframes, triggers, contacts, cooperation duties and evidence obligations.

The fifth failure is unclear exit rights. If a vendor becomes insecure, non-compliant, acquired, insolvent or strategically unsuitable, the buyer needs export, deletion, transition support, account deactivation and destruction evidence. Exit is not a legal afterthought. It is a resilience control.

From procurement gate to living supplier assurance

Secure-by-demand procurement does not end at signature. A mature Clarysec-style supplier lifecycle has five stages.

For high-risk suppliers, monitoring should include evidence refresh, security review meetings, incident tabletop participation, access review, vulnerability and patch reporting, service change review and sub-processor updates. For lower-risk suppliers, annual review may be enough. ISO 27001 scalability, NIS2 proportionality and DORA proportionality all support tailoring, but tailoring must be justified and documented.

The Clarysec next step

The next risky SaaS purchase will not wait for a perfect governance redesign. Start with the next procurement request.

Use the Zenith Blueprint: An Auditor’s 30-Step Roadmap to implement Step 23 supplier relationship controls and Step 21 outsourced development controls. Use Zenith Controls to map ISO/IEC 27002:2022 controls 5.19, 5.20 and 5.21 across NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-oriented audit expectations. Use Clarysec’s policy library, including the Third party and supplier security policy, Application Security Requirements Policy, Cloud Usage Policy and Legal and Regulatory Compliance Policy, to make the gate enforceable.

Before the next contract is signed, require supplier classification, security evidence, DPA readiness, incident commitments, vulnerability handling, subcontractor transparency, audit rights and exit terms.

That is secure-by-demand procurement. It is how CISOs convert regulatory pressure into buying power. It is how compliance managers turn overlapping obligations into one evidence file. It is how auditors see that supplier risk was considered before dependency was created. And it is how business owners buy software faster without inheriting unmanaged risk.

Ready to turn your next software purchase into an audit-ready control? Explore Clarysec’s integrated policy suite, download the Zenith Blueprint, review Zenith Controls or schedule a demo to build a secure-by-demand procurement program that stands up to NIS2, DORA, GDPR, CRA expectations and real auditor scrutiny.