Back to Startup playbook
Data

Data protection assurance

Useful for

Common knowledgeData protectionCustomer trust

Introduction

Data protection should be treated in the same way the product is treated with penetration testing. Before wider customer onboarding, the company should get an external review of its data protection position.

Knowledge scope

This is common CTO knowledge. It applies beyond the startup journey, but the public playbook places it where it usually becomes important for an early-stage company.

Why it matters

As soon as a Pilot accepts external users, personal data may appear. The company needs to understand what it collects, where it is stored, who processes it, how requests are handled and whether it is acting as Controller, Processor or both.

How it fits the playbook

This reference supports the POC Started -> Pilot Ready stage of the startup CTO playbook. It gives the public context for the decision without exposing the deeper assessment method behind the agentic operating model.

Design considerations

  • Start the DPIA and data inventory before Pilot data becomes messy.
  • Record Controller and Processor decisions because they affect contracts and response timings.
  • Make privacy, cookie, retention and vendor positions match reality.
  • Remember company data as well as product data: staff, contractors, prospects and suppliers also matter.
  • Use external review to turn data protection into customer assurance evidence.

What good looks like

The company can explain its data position clearly and can support customer, regulator or data-subject questions without searching through scattered notes.

How Brokenhouse helps

Turn this into a practical plan.

I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.

Talk through your situation

Next guidance

Related decisions to work through

Data

Are we ready for a Pilot?

Before moving from POC to Pilot, the company needs a data governance baseline. This is separate from technical governance. Technical governance asks who can deploy, who can access Azure and how the environment is built. Data governance asks what information the company collects, where it is stored, why it is allowed to hold it and how it protects it.

AI

Agentic software delivery governance

Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not sit in the customer-facing service, but they can still read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.

Data

AI model governance

AI models used by the product need their own governance model. They sit close to customer workflows, user data, automatic processing and contractual promises, so they need stronger control than delivery agents used internally.