Loading insights
Loading insight article
Insights / Governance
Plan data handling, security, AI controls and operational ownership early, with evidence that supports the requirements your product actually faces.
A customer asks where their information will be stored. Someone on your team checks the database region. Then the conversation reaches backups, support access, analytics, uploaded documents and the model processing those documents. The answer becomes less certain.
That uncertainty can begin long before an audit. It begins when product decisions are made without a shared understanding of the information the system handles and the commitments the business expects to make.
Compliance readiness means identifying the requirements a product actually faces, assigning responsibility for meeting them, and keeping evidence that the controls work. It starts with the first decisions about customer information, access and suppliers. The timing of a formal assessment follows the product's obligations and buying requirements.
For a founder, the immediate question is practical: which decisions would be expensive or disruptive to reverse after customers start using the product? That is where I would spend the early engineering effort.
Before choosing a framework, write down what the product will do, who will use it and what could happen if it behaves incorrectly.
A legal document workspace, a public scheduling tool and an AI system that proposes changes to financial records need different discussions. Even within one product, a public help page and a confidential matter workspace have different boundaries.
Useful starting questions include:
Record uncertainties alongside confirmed requirements. An unanswered question about permitted data use should have an owner and a decision point before the relevant data enters a pilot.
Security, privacy, contractual commitments, sector obligations and independent assurance overlap, but they answer different questions.
An access control can help protect information. It does not, by itself, establish whether collecting that information is appropriate. A retention setting can remove old records. It does not decide which retention period applies to a particular customer or whether an approved exception is needed.
SOC 2 has a particular assurance purpose: AICPA describes SOC services as reports that help users assess risks associated with outsourced services. It should not become shorthand for every obligation a product might face. AICPA's SOC overview
Similarly, NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk. It can help structure a discussion without determining all of a business's legal obligations. NIST Privacy Framework
The engineering team should translate confirmed requirements into system behavior. Qualified legal, compliance and assurance specialists determine applicability and the assessments within their remit.
Use a requirements register to distinguish the sources of those requirements:
Scroll horizontally to view all columns.
| Source | Question to resolve | Product implication to investigate |
|---|---|---|
| Applicable law and regulation | Which rules apply to this processing, customer and market? | Collection, notices, access, retention and other behavior specified by the responsible advisers |
| Customer contract | What are we committing to deliver or restrict? | Hosting locations, support access, deletion, incident communication and service commitments |
| Security management or assurance | What organizational scope and evidence will be assessed? | Control ownership, documented operation, review and remediation |
| Internal policy | What has the business authorized? | Approved providers, permitted AI uses, review responsibilities and exceptions |
For example, ISO/IEC 27001 sets requirements for an information security management system. That organizational scope is broader than choosing a hosting provider. ISO's explanation of ISO/IEC 27001
Privacy requirements can also affect design directly. In the UK GDPR context, the ICO explains data protection by design and by default, including integrating safeguards into processing and limiting personal information to what is necessary. Confirm applicability with the responsible adviser rather than treating a general checklist as a legal determination. ICO guidance
Broader planning means considering the relevant categories early. It does not require pursuing every framework in every market. The market-first SaaS strategy article explains how target buyers and their purchasing process help establish which requirements need attention now.
A useful data map follows an item from collection through processing, sharing, storage and eventual disposal. Include the paths that sit outside the main database: file processing, search indexes, telemetry, exports, support access and backups.
For AI features, include prompts, retrieved passages, generated outputs and any stored conversation history. Check the actual provider arrangement before deciding what may be sent, retained or used for another purpose.
This map should change product choices. If a workflow can operate with a reference number, avoid asking for a full document by default. If support staff need diagnostic information, design a way to investigate without routinely exposing customer content.
Collecting less information can also make the product easier to explain and operate.
Take deletion as a design example. Removing an uploaded file may leave extracted text in a search index, a copy in a processing queue and excerpts in diagnostic logs. Write down which copies the product creates, how each is removed or expires, and how backup retention affects the answer given to a customer. Test the complete path with a sample record. This is a proposed engineering check; the required retention and exceptions must come from the agreed policy.
“Secure access” is too broad to implement or verify. Define whose access is checked, against which resource, and at what point.
For a shared legal workspace, a proposed acceptance check might be: removing a user from a matter prevents subsequent retrieval through search, direct document links and connected AI tools. Test those paths separately. A hidden navigation item is insufficient evidence.
Other early decisions include how tenants are separated, how secrets are stored, who can administer production, how changes are reviewed, and what happens when a dependency fails.
Evidence should match the decision. Access tests, configuration records, approved changes and recovery exercises can demonstrate different parts of the operating picture. An architecture diagram alone cannot show that a restore succeeds.
Specify what the system can read, what it can prepare, and which actions require approval. A model may help extract information from an uploaded document while the application independently checks whether the user can access the matter and whether an action is permitted.
Evaluate unsupported answers, missing sources and misleading instructions inside documents, alongside normal examples. Define a route for uncertain work and a way to suspend the affected capability.
NIST's voluntary AI Risk Management Framework places trustworthiness considerations across AI design, development, use and evaluation. That supports treating these questions as continuing product work. NIST AI RMF
Consider a hypothetical product that prepares matter updates from approved records. Before a pilot, its team might record:
Scroll horizontally to view all columns.
| Decision | Proposed implementation | Evidence or responsibility |
|---|---|---|
| Matter access | Check permission before retrieval and again before sending | Engineering tests denied and revoked access |
| Client communication | Prepare a draft; require the assigned reviewer's approval to send | Record the approved version and send result |
| Retention | Apply an agreed schedule across defined storage locations | Product owner confirms policy; engineering verifies behavior and records backup limits |
| Operational failure | Queue failed work for an accountable team member | Operations tests escalation and recovery |
This is an illustration, not a completed compliance assessment or a description of a client deployment.
An early product needs a proportionate plan. Identify what must be in place before real customer information is used, what a named target customer requires before purchase, and what belongs to a later stage. Deferred work needs a reason, an owner and a trigger for reconsideration.
I would organize that work around three decisions:
1. Before a real-data pilot: confirm permitted data, access boundaries, provider arrangements, a recovery path and who handles an incident. Use synthetic material while a required decision remains unresolved.
2. Before a customer commitment: compare the contract and questionnaire against actual behavior. Mark gaps honestly and assign a delivery owner before agreeing to a new capability.
3. During operation: retain evidence of access reviews, changes and recovery checks. Revisit the plan when a system, supplier or customer requirement changes.
The order is a planning recommendation, not a universal compliance timetable. An obligation that already applies cannot be deferred simply because the product is described as an MVP.
Review the plan when a product enters a new market, adds a provider or receives broader authority to act. A change in the workflow can change the risk even when the interface looks familiar.
The first useful deliverable is a set of decisions the team can work from: a data map, a requirements register, explicit boundaries, accountable owners and checks tied to the actual product. That gives founders a clearer build scope and gives customers more concrete answers when they ask how their information will be handled.
My role is technical readiness: designing, implementing and testing software controls. Legal interpretation, compliance determinations and independent assurance belong with the appropriate specialists.
For an application of these boundaries to legal work, continue with choosing a law-firm AI workflow. If you need help implementing the controls, the AI and data governance service describes the technical scope.
Tell me about the system or workflow you are working on.
30-minute intro call on Calendly
