# Secure IT procurement

Connect business need to contract terms, total cost and a safe exit.

SecNet.Work | 2026.10 | 2026-10-21

Procurement, engineering and security contribute different evidence to one decision. The lowest licence price does not explain operation, integration, data migration and exit costs. Define requirements and acceptance tests before comparing suppliers on the same scope. ENISA’s July 2026 guidance focuses on healthcare; this general workflow does not extend its scope into a universal obligation.

## Work boundary
Software, SaaS and managed services. Fictional costs are not quotations; assess tax, exchange rates, discounting and contract escalation separately.

## Process

### 1. Define the need
Have the owner record the use case, data class and outage tolerance. Explain why the current solution is insufficient and what success means. Include security requirements in the bid scope rather than a last-minute questionnaire.

Expected evidence: Requirements and acceptance criteria

### 2. Validate the supplier
Review subprocessors, service regions, support access and incident notification. Check that the legal entity and service in a certificate match the proposed service. Assign an owner and decision date to unanswered questions.

Expected evidence: Scoped due diligence and gaps

### 3. Compare cost
Use one period and currency. Separate annual licence/support from one-off setup, migration and exit. Do not treat a missing quote as zero. Present unmet security and continuity requirements to the risk owner before negotiating them away.

Expected evidence: Assumptions and comparable cost table

### 4. Make the contract actionable
Assign measurable responsibilities for data ownership, access, notification, evidence, subprocessor changes and termination. Legal counsel reviews applicability. Convert marketing promises into acceptance tests.

Expected evidence: Contract terms with owners and timing

### 5. Test acceptance and exit
Test access, logs, restore and data export in a pilot. Ask for scope and exceptions behind deletion claims. Do not show unconditional acceptance while critical unresolved gaps remain.

Expected evidence: Pilot test, open actions and exit record

## One control, three perspectives

### Operator
Can we operate the product securely?
Run pilot access and logging tests.
Evidence: Acceptance test output

### Auditor
Do the bid and evidence cover the same scope?
Match service and certification scope.
Evidence: Requirement-to-evidence mapping

### Leader
Do we know exit cost and risk?
Decide using period, assumptions and open risks.
Evidence: Total cost and risk acceptance

## Evaluate evidence

**Claim:** The service supports a safe exit.

**Weak support:** A brochure says “leave at any time”.

**Stronger support:** Pilot data was exported in a usable format; timing, cost, deletion scope and contractual owners are recorded.

**Rationale:** A promise does not prove portability. Testing must cover data relationships and dependent services.

## Decision desk
A low-price SaaS bid omits exit terms and log access.
Start: start

### start
How do you proceed?

- **Request comparable terms and a pilot** (good)
  You are tying price to the actual service scope. Now test the exit assumptions.
  Next: verify

- **Select the cheapest bid immediately** (risk)
  Hidden dependencies and exit costs are excluded. Treating missing costs as zero distorts comparison.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
The pilot export includes files but omits access permissions.

- **Test permission migration and restore** (good)
  Downloading files alone is not a usable exit. A reuse test including dependencies and permissions is planned.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
The contract is signed and security cannot retrieve logs.

- **Assign an owner, contract amendment and interim monitoring** (good)
  Service ownership and legal review are engaged. Monitor the interim control until durable log access is verified.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Requirement: BUY-001
- Owner: Example service owner
- Bid scope: SaaS + support
- Evidence: Fictional pilot report
- Gap: Permission export missing
- Decision: Conditional; not accepted
- Acceptance test: Restore with permissions pending
- Exit condition: Data + permissions + deletion record

## Closure checklist
- [ ] Requirements defined before bidding.
- [ ] Cost periods and assumptions match.
- [ ] Critical gaps have owners.
- [ ] No closure before exit and acceptance testing.

## Official sources
- [NIST SP 800-161 Rev. 1, November 2024 update](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final)
- [ENISA — Procurement guidelines for hospitals, July 2026](https://www.enisa.europa.eu/publications/procurement-guidelines-for-the-cybersecurity-of-hospitals-and-healthcare-providers)

https://secnet.work/learn/toolkits/secure-procurement