Data Processing and Security
NeateWorks processes personal data for its clients as a processor, on their instructions, under the data-protection terms of the NeateWorks Master Services Agreement. This page is the description of processing (Annex I of the Standard Contractual Clauses) and the technical and organizational security measures (Annex II) those terms refer to. The subprocessors are on a separate list, and NeateWorks' transfer impact assessment is published for clients transferring data from Europe, the UK or Switzerland.
Description of processing (Annex I)
Data exporter (controller)
The client named in the Master Services Agreement, contactable through the notice details it gives there. Its activities relevant to the transfer are receiving the Services described in the Agreement and each Statement of Work.
Data importer (processor)
NeateWorks LLC, a Colorado limited liability company, Denver, Colorado, United States. Contact: Tristan Neate, Member, tristan@neateworks.com. Its activities relevant to the transfer are building, hosting, operating, administering and supporting the client's systems.
Data subjects
End users and customers of the apps and websites NeateWorks builds, hosts or administers for the client. The client's personnel and contractors who use the client portal, the app's admin tools, or correspond with NeateWorks. Anyone else whose personal data the client puts into, or routes through, those systems.
Special categories
None. Special categories of personal data (GDPR Article 9) and criminal-offence data (Article 10) are excluded by the Master Services Agreement unless a Statement of Work expressly agrees otherwise and sets the extra safeguards.
Frequency
Continuous, for the term of the Agreement.
Nature of processing
Hosting, storage, backup, transmission, logging, email delivery, support and troubleshooting access, development and testing, and AI processing where a deliverable includes it.
Purpose
To build, deploy, host, operate, administer, support, maintain, test and troubleshoot the systems and deliverables in each Statement of Work, as the Master Services Agreement instructs.
Transfers to subprocessors
To the subprocessors on the subprocessor list, for the purposes and data stated there, for the duration of the Agreement.
Supervisory authority
The authority competent under Clause 13 of the Standard Contractual Clauses: the one where the data exporter is established or, where it is not established in the EU, where its representative is or where the data subjects are.
Categories of personal data
- Identity and contact details: names, email addresses, phone numbers, postal addresses.
- Account data: usernames, roles and preferences. Passwords are stored only as salted hashes.
- Content users submit: messages, comments, form entries and uploaded files.
- Transaction data: amounts, line items and payment-processor references. No card numbers.
- Technical data: IP addresses, browser user agents and request logs.
- Location data where an app's function needs it, such as a service address.
- Electronic-signature evidence for agreements signed in the portal: name, title, email, signature image, IP address and user agent.
How long data is kept
Production databases and stored files
For the term of the Agreement plus the 30-day post-termination retrieval window, then deleted or returned at the client's direction.
Database backups
Nightly snapshots plus continuous transaction-log archiving, kept for 30 days. Superseded backup objects are purged after 35 days. Data deleted from a live database stays in backups until they age out.
Application and infrastructure logs
30 days.
Expired sign-in tokens and sessions
Purged daily.
AI-assistant connection tokens
Expired access tokens and authorization codes are deleted nightly once they expire. Revoked tokens and revoked assistant approvals are deleted 90 days after revocation. Tokens stop working at expiry or revocation either way. Assistant registrations never approved are deleted after one day.
Portal notifications
Deleted 90 days after being read, and in any case 1 year after creation.
Portal audit trail
Deleted after 2 years.
Audit-trail entries for agreements (status and signing changes)
Kept for the life of the agreement, plus 7 years after it is voided or deleted.
Signed agreements and their signing evidence (signer IP address, signature and timestamps)
Kept for the life of the agreement, as contract evidence. No copies of the signature, IP address or browser details are kept in the audit trail.
Comments
Kept while the client organization, project or item they are on exists and the author's account remains. Deleted with the author's account, and within a day of the item they are on being deleted. Their copies in the audit trail are deleted after 2 years.
Security measures (Annex II)
NeateWorks maintains the measures below for every system it hosts. It may improve them over time, but will not change them in a way that materially reduces the overall protection they provide.
Encryption
- All traffic to every app uses HTTPS with Google-managed TLS certificates. Plain HTTP is redirected to HTTPS, and app APIs send a one-year HSTS header.
- Google Cloud encrypts all stored data at rest by default: databases' disks, file storage and backups.
- Stored third-party credentials (such as bank- or exchange-connection secrets) are additionally encrypted field by field, with rotatable keys, in the apps that hold them.
- Passwords are stored only as salted PBKDF2 hashes. AI-assistant access tokens, authorization codes and client secrets are stored only as SHA-256 hashes.
Access control
- Anything that is not deliberately public requires a signed-in user. Sign-in access tokens are short-lived: five minutes in the client portal and the client apps NeateWorks hosts.
- The server, not the browser, decides what each person sees: users get their own records or their organization's, internal records are hidden from clients, and staff-only actions are refused to everyone else.
- Resetting a password revokes every existing sign-in session and every AI-assistant connection the account had.
- AI-assistant access is per person and limited to what that person's own permissions allow. Personal access tokens are read-only, a connected assistant can change data only where the person approved that, and connected-assistant access tokens expire after one hour.
- Sign-in, password-reset and other endpoints are rate-limited, and each app's API accepts cross-origin requests only from that app's own website.
Infrastructure and secrets
- Each app runs under its own Google service account through Workload Identity, with no downloadable keys. Email is sent by signing through Google IAM rather than with a stored key.
- Deployments run only through automated pipelines that authenticate to Google Cloud with short-lived federated credentials, not stored cloud keys.
- Database passwords, signing keys and payment-provider keys are held as Kubernetes Secrets and injected at runtime.
- The operations portal's own cluster access is limited: it cannot read Kubernetes Secrets, change access rights or create namespaces, and reads historical logs only through two narrow, filtered views.
- Credential-shaped text (bearer tokens, API keys, passwords in URLs) is redacted from logs before they are shown in the portal or to the AI assistant.
- Development and production use separate database clusters, separate credentials and separate namespaces, so a development deployment holds no credentials for production data. Each client's app data sits in its own database cluster, apart from NeateWorks' own apps.
- Every regional resource lives in us-central1. An automated test fails any change that would create one elsewhere.
- Cluster nodes are Google Shielded GKE nodes.
Availability and recovery
- Production databases run as a primary with a hot standby, replicated synchronously whenever the standby is available.
- Databases are backed up nightly, with continuous transaction-log archiving, to versioned Cloud Storage in us-central1, kept for 30 days.
- Every week an automated job restores the newest backup into a throwaway database and checks it, then deletes it.
- Uptime checks probe every app hostname every five minutes and alert on failure. Separate alerts cover TLS certificates 15 days before expiry, failed backups, failed scheduled jobs and failed deployments.
Secure development
- Changes are merged through pull requests that run automated backend and frontend tests and lint checks against temporary test databases with no production data.
- Dependabot proposes dependency updates weekly, and third-party CI actions are pinned to exact commits.
People and accountability
- Only NeateWorks personnel who need access to a system have it, and each is bound by a duty of confidentiality.
- The client portal keeps an audit trail of every create, update and delete of its core records (organizations, projects, tasks, comments, files and more): who, what changed and when.
- Signed agreements are stored with a SHA-256 fingerprint of the exact text signed, and cannot be edited afterwards.
- NeateWorks notifies the client without undue delay after becoming aware of a breach affecting its personal data, and helps it respond to data-subject requests and assessments.