Procurement guide

Security review:
questions and evidence

A practical way to evaluate a PACX deployment without relying on an unverified badge, a generic promise or a control that is outside your contract.

7 min readSecurity · Privacy · ProcurementEvidence-led reviewPage updated August 22, 2026

Examples describe a configurable workflow, not a contractual commitment. Confirm security, retention, schedules, integrations and automation for your own deployment before relying on them.

On this page

What this page does — and does not — assert

A public checklist is not a certificate, audit report or contractual control schedule.

This guide explains how to run the review. It does not claim that PACX holds a particular certification, uses a particular hosting region or has completed a named audit. Those are time-sensitive facts that need a current artefact and an authorised owner before they appear as public claims.

Contract over copy

Translate controls that matter to your risk decision into scoped, reviewable terms.

Artefact over badge

Check the date, scope, exceptions and owner of each piece of evidence.

Deployment over assumption

Confirm which environment, data path and subprocessor set the answer covers.

Define the data scope first

Security review starts with what data is needed, why it is needed and where it will move.

Begin with a data inventory. For every proposed field, record the business purpose, source system, classification, transfer cadence, retention need and people who should be able to use it. Remove fields that are not needed for the agreed planning decision.

Question; What a review-ready answer contains
Question	What a review-ready answer contains
What enters the service?	An explicit field-level inventory, including identifiers and free-text fields.
Why is it processed?	A purpose tied to the agreed workflow, with optional uses separated from required ones.
Where does it move?	A data-flow diagram covering ingestion, processing, exports, logs, backups and subprocessors.
Who is responsible?	Named business, technical, privacy and incident contacts on both sides.
When does it leave?	Retention, return and deletion events with treatment of backups and legal holds.

Minimise before transferring

Use synthetic data for evaluation when production data is not required.
Exclude direct personal identifiers unless the reviewed scope and agreement explicitly require them.
Keep free-text columns out of routine feeds unless their contents and purpose can be controlled.
Document derived fields so deletion and access requests can follow the full lineage.

The evidence pack to request

Ask for current artefacts, named owners and explicit scope instead of accepting badges.

A useful evidence pack lets a reviewer connect a written control to a current operating record. It should make gaps and exceptions visible rather than forcing the reviewer to infer them.

Area; Evidence to request; Review closely
Area	Evidence to request	Review closely
System and data-flow scope	A current architecture and data-flow diagram naming stores, regions, trust boundaries and subprocessors.	Document version, owner, review date and the exact service or environment covered.
Identity and access	Authentication configuration, role model, privileged-access process and access-review evidence.	How support access is granted, approved, logged, reviewed and revoked.
Encryption and key management	Transport and storage configurations plus the key ownership, rotation and recovery process.	Algorithms, protocol floors, exceptions and which copies or backups are in scope.
Secure development	Change-control, dependency, vulnerability-management and security-testing records.	Evidence from the current release process, not a policy with no operating record.
Continuity and recovery	Backup scope, restoration tests, recovery objectives and the latest exercise record.	Whether the objectives are contractual and what dependencies they assume.
Independent assurance	Any current audit or assessment report the vendor is authorised to share.	Period covered, exclusions, exceptions and management responses; never infer status from a logo.

Two public reference frameworks can help structure the questions: the NIST Cybersecurity Framework and the OWASP Application Security Verification Standard. A framework is a checklist aid; it is not evidence that a vendor operates a control.

Access and operational governance

Review how identities, privileges, support access and changes are controlled for your deployment.

Review access as a lifecycle rather than a login screen. The evidence should show how an identity is created, what grants privilege, how sensitive actions are approved, what is recorded and how access ends.

1
Map roles to real jobs
List permissions by role and test them against planner, approver, administrator and support responsibilities.
2
Separate routine and privileged access
Ask how elevated access is requested, time-bounded, reviewed and associated with a named person.
3
Test the record
Choose a sensitive action and ask what record it creates, who can review it and how long that record remains available.
4
Exercise removal
Include leavers, role changes, compromised credentials and vendor support access in the offboarding test.

Retention, return and deletion

Put dates, backup treatment and evidence of completion into the agreement.

Avoid phrases such as “retained as needed.” Define a period or a clear event for each data class, identify the system of record, and state what happens to derived output, logs, archives and backups.

Lifecycle point; Terms to settle
Lifecycle point	Terms to settle
During service	Per-data-class retention, legal holds, version history and who may change the setting.
On request	Authorised requesters, scope confirmation, completion target, exceptions and evidence returned.
At termination	Export format, return window, deletion trigger and responsibility for downloaded copies.
In backups	Backup expiry or overwrite process, restore controls and treatment after a primary deletion.

Incident readiness

Agree contacts, notification triggers and response evidence before an incident occurs.

Incident language should identify the event that triggers notification, the contact path, the information supplied, the update cadence and the post-incident evidence. Align the contractual timetable with the laws and internal escalation duties that apply to your organisation.

Name primary and out-of-hours contacts on both sides.
Distinguish a suspected event, a confirmed incident and a breach of protected data.
Define the minimum first notice: known scope, time detected, containment status and next update.
Agree how forensic evidence is preserved and how root-cause and corrective-action reports are shared.
Run a tabletop exercise before production data is introduced.

Questions for procurement

A short list that exposes ambiguous answers early.

Which assurance artefacts are current today?: Request the document, period, scope and exceptions. A future plan is not current assurance.
Which subprocessors touch our data?: Ask for purpose, location, data category, contractual role and change-notification process.
Can PACX personnel access our deployment?: Require a scoped answer covering normal operations, support, emergencies, approval, logging and review.
Is our data used for model training?: Put the permitted and prohibited uses, including derived and de-identified data, into the agreement.
How do we verify deletion?: Agree the scope, target time, backup treatment, exceptions and completion evidence before data is supplied.
What happens when a control changes?: Define which changes require notice, a new review or consent, and who owns the resulting decision.

Request the current security evidence pack

Bring your data-flow, control and legal questions. The answer should be scoped to the deployment you are evaluating.

Start a security review