Secure-by-Design Website Procurement: Questions to Ask Before Selecting a Platform or Agency

Every shortlisted platform is “secure”. Every capable agency “follows best practice”. Those statements tell a buyer almost nothing.

The useful questions are more specific. What security assumptions shape the architecture? How are dependencies selected and updated? Who can access production? What evidence will exist before launch? Who monitors an incident at 2 am? Which party restores the site, rotates secrets, communicates with users and verifies recovery?

These questions reveal an uncomfortable truth: website security is not a feature attached to a platform. It is the result of choices and responsibilities distributed across the client, agency, software vendors, identity services, hosting provider and ongoing support team.

Secure-by-design procurement brings those decisions forward. The Australian Cyber Security Centre describes secure by design as making security a core business requirement across a product’s lifecycle, beginning in the design and development phase. Procurement should therefore test the delivery system and operating model, not just the final website specification.

This guide provides an evidence-led framework for doing that. It is general procurement information, not legal, cyber-security or compliance advice for a particular organisation.

Begin with consequence, not a generic questionnaire

A five-page marketing site and a customer portal holding sensitive records should not face the same procurement process. A generic list either overburdens low-risk work or fails to examine high-risk systems.

Start by classifying the proposed service across these dimensions:

• Information: what personal, confidential, payment or regulated information will pass through or be accessible from the website?
• Transactions: can users place orders, change account details, submit claims or create binding instructions?
• Identity: are there customer, partner, staff or administrator accounts, and what authority do they carry?
• Availability: what operational, revenue or reputational consequence follows an outage?
• Integrations: which CRM, ERP, payment, identity, marketing or data services are connected?
• Reach: how many users, brands, markets and internal teams depend on the service?
• Change: how frequently will code, content, plugins and campaigns change?

Use the result to set an assurance tier. A low-consequence brochure site may need proportionate baseline controls and evidence. A commerce or authenticated platform may require architecture review, threat modelling, independent testing, recovery exercises and stronger operational commitments.

Define unacceptable outcomes

Risk language becomes useful when it names events. Examples include:

• an unauthorised person exports customer records;
• an administrator account is taken over;
• malicious code enters through a dependency;
• a form sends information to an unintended recipient;
• a deployment exposes secrets or a development environment;
• the site cannot be restored within the business tolerance; or
• a supplier incident is discovered but nobody owns response.

Ask bidders to explain how their proposed design reduces the likelihood or impact of the relevant outcomes. This produces more insight than asking whether they “comply with security best practice”.

Evaluate evidence, not confidence

Secure procurement is not a hunt for a perfect certificate. It asks for evidence appropriate to the risk and delivery stage.

The CISA Secure by Demand Guide encourages software customers to demand security as a core product consideration and evaluate manufacturers’ secure-by-design practices. For website procurement, an evidence ladder may include:

Claim	Weak response	More useful evidence
“We develop securely”	A policy statement	Documented development lifecycle, review gates and sample deliverables
“The platform is kept updated”	“Updates are automatic”	Ownership, cadence, testing, exceptions and version reporting
“Access is controlled”	“Only our team has access”	Role model, MFA, approval, expiry and access-review procedure
“We test security”	An automated scan screenshot	Defined test scope, tester independence, severity method, remediation and retest evidence
“Backups are included”	A retention number	Scope, isolation, encryption, restore responsibility and recent restore-test evidence
“We handle incidents”	A support email	Detection, severity, contact path, responsibilities, timing and exercise record

The bidder may need confidentiality protections before sharing detailed evidence. That is reasonable. Refusing to explain the process at any useful level is different.

Ask whether evidence applies to your solution

A vendor’s corporate certification may cover one product or office while the proposed hosting, subcontractor or custom code sits outside scope. Ask what entity, service, locations and period the evidence covers. Similarly, a platform penetration test does not prove that a custom implementation, integration or deployment is sound.

Ask how security shapes the delivery lifecycle

NIST’s Secure Software Development Framework groups secure development practices around preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. A website buyer can translate that into practical procurement questions.

Requirements and architecture

Ask:

• How will security and privacy requirements be identified and accepted?
• Which trust boundaries, privileged actions and sensitive data flows will be documented?
• When is threat modelling appropriate, and who participates?
• How are platform and integration choices assessed against the risk profile?
• Which controls are inherited from vendors, and which must be implemented?
• How are administrative, customer and machine identities separated?

Look for a method that can show decisions and assumptions, not a promise to “consider security throughout”.

Development and change control

Ask:

• How are code changes reviewed and approved?
• How are development, testing and production environments separated?
• How are credentials and secrets stored, rotated and kept out of source code?
• What automated checks run in the delivery pipeline?
• Who may deploy to production, and how is emergency change handled?
• How are configuration and infrastructure changes recorded?

For a configurable CMS, include content-side capabilities that can execute scripts, alter form destinations or change integrations. Editorial access can be security-sensitive even when no code is changed.

Verification and release

Ask:

• Which tests are included in the implementation scope?
• What triggers independent penetration testing or specialist review?
• Which standard or test basis will be used?
• How are findings classified, assigned, retested and accepted?
• What security criteria must be met before launch?
• Who can accept residual risk on behalf of the client?

The OWASP Application Security Verification Standard can provide a structured basis for testing web application security controls. Procurement documents should specify the required assurance outcome and evidence rather than merely saying “OWASP compliant”.

Examine platform and supply-chain risk

A website depends on far more software than its visible CMS. It may include a runtime, operating system, themes, plugins, packages, tag-manager scripts, payment libraries, CDNs, search, forms, identity and marketing services.

The ACSC’s Guidelines for Cyber Security Roles of Chief Information Security Officers reinforce the need for clear responsibility, while its cyber supply-chain guidance recommends understanding dependencies and managing supplier risk across the lifecycle.

Ask platform and agency candidates:

• Which core products, plugins, packages and external services are proposed?
• Who approves a new dependency, and on what criteria?
• Is there an inventory or software bill of materials for the implemented solution?
• How are vulnerability notices received and matched to deployed versions?
• What happens when a dependency is abandoned or reaches end of support?
• How quickly are critical issues assessed, and who has authority to act?
• Can a third-party script be disabled without a full release?
• Which subcontractors or offshore teams may access code, data or environments?

Do not assume fewer dependencies always means lower risk. A custom component can be poorly maintained too. The decision needs visibility, ownership and an update path.

Challenge plugin-first solutioning

In ecosystems with large plugin marketplaces, installing another extension can be the fastest way to demonstrate a feature. It also adds code, update cycles, vendor reliance and possible data flows. Require a justification for each material extension: business need, maintained alternatives, permissions, data access, update history, licence, replacement path and owner.

Make access ownership explicit

Procurement should identify every privileged surface:

• CMS administration;
• hosting and cloud control plane;
• domain registrar and DNS;
• source-code repository and delivery pipeline;
• analytics, tag manager and consent tools;
• payment, CRM, email and identity services;
• backups, monitoring and security tools; and
• third-party support portals.

For each, define the account owner, day-to-day administrators, MFA requirement, joiner/mover/leaver process, emergency access and log availability. The client should retain appropriate organisational control over critical accounts and assets rather than depending on a departing supplier’s shared credential.

OWASP’s Authorisation Cheat Sheet recommends least privilege and deny-by-default behaviour. Apply the principle not only inside the public application but to the people and tools that can change it.

Separate hosting, website support and security operations

“Managed” is not a precise responsibility description. A hosting provider may operate infrastructure while nobody is contracted to update the CMS. An agency may maintain application code while the client owns incident monitoring. A platform vendor may patch its service while custom integrations remain the implementation team’s responsibility.

Build a responsibility matrix for at least:

Activity	Decision to make before contract
Hosting platform operation	Who contracts the host and handles infrastructure incidents?
CMS and dependency updates	Who assesses, tests, schedules and verifies them?
Monitoring and alert triage	Which signals exist, who receives them and when?
Vulnerability handling	Who assesses exposure, fixes, retests and communicates?
Backups and restoration	What is backed up, by whom, and who proves restore works?
Incident response	Who leads technical containment, business decisions and notifications?
Access reviews	Who reviews supplier, staff and service accounts?
Security testing	Who commissions it, receives findings and accepts residual risk?

Emote does not sell or resell hosting; clients contract their selected hosting provider directly. In any supplier model, that commercial boundary should be accompanied by an operational map showing how the provider, implementation partner and client coordinate.

Procure service levels for the real need

A response target is not necessarily a resolution target, and business-hours support is not 24/7 monitoring. Ask which events trigger support, the covered hours, severity definitions, communication channels, exclusions, dependencies and client obligations. If rapid restoration matters, ensure the hosting and application support arrangements can collectively deliver it.

Procure backup and recovery as a tested capability

A checkbox saying “daily backups” omits the decisions that matter:

• Does the backup include database, uploaded files, configuration, code and infrastructure definitions?
• Is it protected from the same credentials or incident affecting production?
• How long are versions retained?
• Are backups encrypted and access logged?
• What recovery point and recovery time does the business need?
• Who initiates and performs restoration?
• How often is a representative restore tested?
• How is restored data reconciled with transactions that occurred after the recovery point?

The ACSC Information Security Manual is one authoritative Australian source for security-control guidance. Your website may not be required to use the ISM, but procurement should still turn recovery needs into owned and testable requirements.

Recovery design also needs business input. A technically restored site may still be unusable if payment credentials, DNS, integrations or administrator access remain compromised.

Address personal information and privacy engineering

Security procurement should map personal-information flows rather than assuming a privacy policy resolves them. Identify form submissions, account data, analytics identifiers, recordings, marketing transfers, logs, backups and supplier access.

The OAIC Privacy Impact Assessment tool describes a PIA as a systematic assessment of a project that identifies privacy impacts and recommends how to manage them. Whether a formal PIA is appropriate depends on the project and applicable obligations, but procurement should ask who will assess privacy risks and at what stage.

Ask:

• What personal information does each service receive and why?
• Where is it stored and transferred?
• Which suppliers can access it?
• Can lower-risk designs collect or retain less?
• How do retention, deletion and user-request processes work across systems?
• What logs or analytics may contain identifiers?
• Who owns notices, consent choices and contractual assessment?

Obtain legal and privacy advice specific to the organisation where needed. The agency should support implementation of agreed requirements without presenting itself as the client’s legal adviser.

Make exit and transition part of security

Supplier and platform exit can create a period of elevated access and weak ownership. Before signing, define:

• ownership and exportability of code, content, media, data and configuration;
• access to repositories, accounts, architecture records and runbooks;
• formats and effort required for export;
• assistance, timing and fees for transition;
• revocation of supplier identities and credentials;
• deletion or return of retained data; and
• continued vulnerability handling during the handover.

The ACSC’s Guidelines for Procurement and Outsourcing make the broader point that cyber security considerations should be addressed across procurement and outsourced arrangements. Exit is part of that lifecycle, not an issue to improvise at contract end.

Score the proposed operating model

A secure procurement scorecard should combine capability, evidence and responsibility clarity.

Suggested weighted categories are:

1. Risk and architecture — 20%: understanding of data, threats, trust boundaries and design trade-offs.
2. Secure delivery — 15%: code, environment, secret and change controls.
3. Platform and supply chain — 15%: dependency inventory, updates and vendor management.
4. Identity and access — 10%: application and operational access controls.
5. Verification — 15%: test coverage, independence, remediation and release gates.
6. Operations and recovery — 15%: monitoring, incidents, backup, restore and support.
7. Evidence and transparency — 10%: relevant artefacts, limitations and willingness to expose assumptions.

Set minimum gates for unacceptable risks rather than allowing visual design or price to compensate mathematically for a critical control gap. Record assumptions and clarifications as part of the evaluation record.

Red flags in a website security response

Be cautious when a response:

• promises that a platform cannot be hacked;
• relies entirely on the hosting provider without defining application duties;
• says updates are automatic but cannot explain testing or exceptions;
• uses “OWASP compliant” without a version, scope or evidence;
• treats a plugin count as proof of capability;
• refuses to identify dependencies or subcontractors;
• cannot explain production access and offboarding;
• includes penetration testing but no remediation or retest;
• describes backups without restore tests;
• leaves incident ownership until after launch; or
• makes security dependent on an unspecified future support package.

Good suppliers will identify boundaries and residual risks. Certainty where evidence is impossible is less reassuring than a precise explanation of controls, limitations and decisions.

What belongs in paid Discovery

When a website includes complex integrations, authenticated users, sensitive information, unusual availability needs, legacy migration or unclear operational ownership, suppliers may not be able to design and price secure implementation from a short brief.

Paid Discovery can map information flows, trust boundaries, roles, integrations, platform options, threat scenarios, assurance needs and the responsibility model. It should produce requirements and architecture decisions that can be costed and evaluated. It is not a free security audit or free strategy exercise provided as part of competitive pitching.

Specialist legal, privacy, penetration testing or security advisory work may still be needed. Discovery should identify those dependencies and place them at the right points in the plan.

A practical shortlist request

Ask each shortlisted platform or agency to provide:

• a solution and responsibility diagram;
• key security assumptions and exclusions;
• the proposed secure-development and change process;
• a dependency and update-management approach;
• access and environment controls;
• a verification plan with remediation and retest;
• monitoring, incident, backup and restore responsibilities;
• a transition and asset-ownership plan; and
• two scenario responses: one vulnerability and one service-recovery event.

This request does not guarantee security. It creates a much stronger basis for comparing how candidates think, deliver and operate.

Frequently asked questions

What does secure by design mean in website procurement?

It means security is treated as a core requirement from scope and architecture through development, testing, launch, operation and retirement. Procurement evaluates how the platform and delivery partner manage that lifecycle rather than adding a security scan at the end.

Is choosing a well-known CMS enough to make a website secure?

No. Platform controls matter, but security also depends on configuration, custom code, dependencies, identity, integrations, hosting, access, updates and operations. Procurement should examine the implemented system and responsibility model.

What security evidence should an agency provide?

Evidence should match the project’s risk. It may include secure-development procedures, architecture artefacts, access processes, dependency practices, test plans, sample redacted reports, remediation records and operational runbooks. Confirm that any certification or test applies to the proposed service.

Should penetration testing be included in every website project?

Not necessarily at the same depth. The need, scope and independence should reflect information, transactions, identity, integrations and consequence. Higher-risk applications commonly justify specialist testing, while lower-risk sites still need appropriate verification.

Who is responsible for website security after launch?

Usually several parties. The client, hosting provider, platform vendor, implementation partner and support team may each own different controls. A responsibility matrix should name update, monitoring, incident, backup, restore, access and decision duties before launch.

Are automatic updates always preferable?

They can shorten exposure for some issues, but the right approach depends on compatibility, testing, rollback and the consequence of failure. Ask which updates are automatic, who monitors outcomes, how exceptions work and how deployed versions are reported.

Why ask about exit during procurement?

Secure transition requires access to code, data, configuration, accounts and documentation, plus controlled revocation of the departing supplier. Agreeing ownership, formats, assistance and deletion obligations early reduces lock-in and handover risk.

When should paid Discovery precede a website quote?

Use paid Discovery when sensitive data, integrations, identity, availability, migration or operational responsibility is too uncertain for a defensible solution and price. It turns those unknowns into requirements and decisions; it is not free security consulting.

How Emote can help

Emote helps organisations translate website goals, integrations and risk considerations into an implementable delivery scope. Where material unknowns prevent responsible estimation, paid Discovery can define journeys, data flows, platform boundaries, responsibilities and assurance requirements before the organisation commits to a solution.

Use Emote’s guide to compare website proposals on more than price when assessing the evidence behind competing approaches.

Preparing a secure website procurement process? Book a meeting with Emote to discuss the brief and delivery pathway.