Agree the data boundaries before connecting systems

This page explains the approach I propose for project work. The signed agreement confirms the practices and responsibilities for your engagement. Website inquiries and bookings are covered by the privacy notice.

Before access

The scope should name the systems, permitted data categories and destinations, allowed actions, business owner, and required approvals. Access should serve the agreed workflow and have a defined end point.

I would ask for synthetic or appropriately redacted examples where they are sufficient. A production connection requires a decision about the records and permissions needed. Sensitive or regulated information needs an appropriate assessment and agreement before processing.

Accounts and credentials

My proposed starting point is client-owned accounts where practical, named invitations, and permissions limited to the agreed work. Multi-factor authentication should be enabled where supported. Please do not send shared master passwords through the website, email, or booking notes.

The project agreement should specify how credentials are supplied and stored, who can access them, and how access is revoked or rotated. Vendor account models and licensing may limit transfers; those limits belong in the scope.

AI services and other providers

Before project information is sent to an AI service or another provider, the project needs an agreed destination and review of the relevant account settings and terms. Provider choice can affect retention, model-training settings, processing locations, and deletion options.

I would document approved services and configuration for the project. The agreement should identify any required data-processing terms. Claims about where data stays or whether it can be used for training must be checked against the actual provider and configuration.

Human approval and failure handling

An approval map should identify where a person checks a draft, resolves an uncertain match, or authorizes a consequential action. Instructions inside a form or document are input data; they must not grant permissions or rewrite the operating rules.

The scope should define logs, excluded details, access to records, and retention. It should name the person responsible for alerts, failed items, manual fallback, incident escalation, and recovery. The proposed failure paths need testing in the actual environment.

Monitoring coverage, response targets, and maintenance capacity belong in a Care agreement when Care is included. A response target concerns acknowledgment and triage; a resolution commitment needs its own definition. A completed Build does not by itself establish ongoing monitoring.

Handover and removal of access

The agreed handover should include the workflow map, available configuration exports, dependencies, operating instructions, test record, and known limits. It should identify account ownership and explain how another operator can make routine changes or handle a failure.

The agreement should also define access review, revocation, credential rotation where needed, and return or deletion of project data at the end of the engagement. Retention periods, deletion timing, and provider backup limits should be written into the project terms.

Ask about the details

I am Gabe Williams Glenn, trading as Novren and publicly known as Gabe Glenn. Send project data-handling questions to hello@novren.co. I can discuss these boundaries before a proposed engagement is agreed.