Data Policy

This Data Policy describes, in operational terms, where data lives in NurtureCRM, how tenants are kept apart, how data is backed up and deleted, and what happens to mailbox credentials. It complements the Privacy Policy, which covers the legal basis and rights side of the same subject.

1. Data categories

Category	Examples	Where it lives
Platform account data	Company, subdomain, tier, administrator contact details, subscription and payment status	Control-plane database
Platform operational data	Provisioning and deployment events, module install records, backup run history, audit records	Control-plane database
CRM records	Contacts, companies, deals, pipelines, activities, notes, tasks, bookings, form submissions	The Customer's own tenant database
Mail content	Messages, threads, headers and metadata ingested from connected mailboxes	The Customer's own tenant database
Files and attachments	Uploads, generated documents, media	The Customer's own object storage
Mailbox credentials	OAuth access and refresh tokens for connected mailboxes	Encrypted at rest; see section 6
Provider secrets	OAuth client secrets and signing keys for Microsoft and Google	Held by the control plane only; never written into a tenant container

2. Storage and infrastructure

• The platform runs on Amazon Web Services infrastructure in the United States.
• DNS and edge termination are provided by Cloudflare.
• TLS certificates are issued and renewed automatically; all external traffic is served over HTTPS.
• Payments are processed by Stripe. Card details are collected by Stripe and are never stored by us.

3. Isolation model

Isolation is structural, not a filter applied to a shared table.

Each Customer receives:

• its own application container — a dedicated runtime process, not a shared worker pool;
• its own database — CRM records and mail content for one Customer are stored in a database that holds no other Customer's records;
• its own object storage — files and attachments are stored in a bucket scoped to that Customer; and
• its own container network, so tenant containers cannot address one another.

Access from the control plane to a tenant runtime is authenticated per instance with keyed credentials derived for that tenant, rather than with a shared platform secret. A credential leaked from one tenant cannot be replayed against another.

4. Processing

Data is processed to deliver the features a Customer has enabled:

• serving the CRM and its records;
• ingesting and displaying mail from connected mailboxes;
• sending mail the user composes, as the consenting mailbox owner;
• running AI features when a user invokes them, as described in the AI Policy; and
• operating, monitoring, backing up and securing the Service.

We do not process Customer data for advertising, for cross-customer analytics, or to train machine learning models.

5. Backups and recovery

• Tenant databases are archived on a scheduled cycle, every 24 hours by default, one archive per live tenant database so a single Customer can be restored without touching any other.
• The control-plane database is archived on the same cycle.
• Scheduled archives are pruned on a 7-day retention window by default.
• Archives taken immediately before a destructive operation — such as the pre-drop archive written when an instance is terminated — are excluded from that prune, because a pruned pre-drop archive could be the only remaining copy.
• Restores are verified, not assumed. An automated drill restores from a recent archive on a recurring schedule and records the outcome, so a silently corrupt backup is discovered by the drill rather than by an incident.

Backup archives contain Customer data and are treated with database-level sensitivity.

6. Mailbox credentials and revocation

• OAuth access and refresh tokens for connected mailboxes are encrypted at rest using envelope encryption.
• Tokens are held for the tenant that owns the mailbox connection and are used only to serve that tenant's unified inbox.
• Provider client secrets are held by the control plane and are never stamped into a tenant container, so a compromised tenant container does not yield the platform's provider credentials.
• Revocation — by the mailbox owner, by a Customer administrator, or at the provider — tears down the provider-side change subscriptions and marks the stored token revoked so it can no longer be used to reach the mailbox.
• The revoked token record is retained for audit rather than deleted. Deleting it would destroy the record of who connected which mailbox and when, which is exactly the question an audit or an incident investigation asks.
• Revocation stops further ingestion. Mail already ingested belongs to the Customer and is deleted on the Customer's instruction or under section 8.

7. Retention

Data	Retention
CRM records and mail content	Held while the Customer keeps them; deleted on the Customer's instruction
Mailbox tokens	Until revoked; retained thereafter in a revoked state for audit
Scheduled backup archives	7 days by default
Pre-drop safety archives	Retained; excluded from automated pruning
Backup run history	Retained after the archives themselves are pruned — history survives its archives
Audit and module logs	Retained for the life of the account
Account and billing records	For the life of the account, and thereafter as tax, accounting and legal obligations require

8. Deletion on termination

When an account is terminated:

1. the Customer's instance is suspended;
2. a pre-drop archive is taken and the tenant database is dropped from active service;
3. a 90-day export window runs, during which the Customer may request an export; and
4. after the window, the archived data is permanently deleted.

Steps 1 to 3 are reversible on request within the window. Step 4 is not.

Individual record deletion inside the Service is immediate in the tenant database and propagates to subsequent backups as the retention window rolls forward.

9. Portability

Customers may request an export of their CRM data and mail content at any time, and during the 90-day window after termination. Exports are provided in a machine-readable format.

10. Module data and the module audit log

Modules extend the Service and may read and write data in the Customer's tenant database, within the permission scopes the Customer allocated at install time.

• A module cannot widen its own scopes.
• Module actions are recorded in a module audit log available to the Customer's administrators, so it is answerable which module did what.
• Disabling a module — including the automatic disable that follows a tier downgrade — retains the data the module wrote; it stops the module from running.
• Uninstalling a module removes the module, not the Customer's records, unless the Customer asks for that data to be deleted.

11. Breach response

If we become aware of a personal data breach we will:

• contain and investigate it;
• notify affected Customers without undue delay, and within the period applicable law requires;
• describe what happened, what data was involved and what we are doing about it; and
• support Customers in meeting their own notification obligations as controllers.

12. Sub-processors

The third parties that process data on our behalf are listed, with purpose, data categories and region, at Sub-processors.

13. Contact

AiCoaches dot com LLC 111 NE 1ST ST, 8TH FLOOR 89145, Miami, Florida, USA 33132 Data enquiries: support@aicoaches.com