Customer trust pack

Introduction

The governance work should produce useful client onboarding evidence. This is not compliance for its own sake. It helps sales and onboarding because the company can answer trust questions quickly and consistently.

Many early SaaS companies discover this too late. The product is ready, the customer is interested, and then procurement asks for security, data protection, support and resilience evidence. If the team has to invent that evidence during the sales process, the deal slows down and confidence drops.

What the trust pack is for

The trust pack is a curated set of customer-safe documents that explains how the company protects data, manages access, responds to incidents and operates the service.

It should not expose sensitive implementation detail. It should give enough confidence for a prospective customer to understand that the company is organised, deliberate and realistic about its controls.

Detailed contents

• Privacy policy.
• Cookie position.
• Data processing agreement or data processing terms.
• Controller/Processor explanation.
• Subprocessor list.
• Security summary.
• Data protection review summary.
• Penetration test summary.
• Support process.
• Incident notification position.
• Standard security questionnaire answers.
• Architecture overview at a safe level of detail.
• Backup and retention summary.
• Recovery point and recovery time position, backed by restore or failover evidence where stated.
• Access control summary.
• Business continuity and recovery summary.

How to keep it useful

The trust pack should be versioned and reviewed. If it becomes stale, it becomes dangerous. The document should match the real operating model, not the operating model the company wishes it had.

A useful approach is to keep detailed internal procedures separately, then publish short customer summaries. The summary says what the company does. The internal procedure proves how it is done.

Where the trust pack mentions recovery, the wording should be backed by evidence. RPO and RTO claims should match contracts, support promises and the latest restore or failover test records. If the tested recovery position worsens, the customer-facing wording should be reviewed and the risk should be assessed before the claim is reused.

How this evolves as the company grows

• Before Pilot, start collecting evidence rather than waiting for procurement questions.

• Before Production, turn security, data protection, support and resilience evidence into customer-safe summaries.

• At Production, keep the trust pack aligned with real controls, external review, penetration testing and support promises.

• As the company scales, the trust pack should become a maintained sales and onboarding asset, not a one-off document.

What an agent should look for

• Is evidence current and customer-safe?

• Do claims match controls?

• Which gaps would slow onboarding?

What good looks like

The company can explain the decision, show the evidence behind it and identify the next point where the control needs to mature.