Data processing agreement

The scope is narrower than “your CRM”. We store the union of the attributes a publisher’s views need and nothing outside that set is ever written to our database. Attributes a filter tests are not stored at all, because Attio evaluates the filter. The full rule, including the two kinds of attribute we store and never display, is on the security page.

3. Instructions

We process personal data only on the publisher’s documented instructions. Those instructions are: this agreement, the terms of service, and the configuration the publisher sets in the dashboard, which is the operative one. The view’s source and filter, the visible attributes, the editable attributes, the access policy and the publish, pause and delete actions are the instructions, and the system executes them and nothing beyond them.

We will tell a publisher if an instruction appears to breach data protection law, and we will not act on a request to widen what a page shows beyond what the configuration expresses.

4. Confidentiality

Everybody with access to personal data processed under this agreement is bound to confidentiality, and access is limited to those who need it to run or support the service. Support access to a customer’s configuration is logged.

5. Security measures

The measures below are what the system does today, not a list of intentions. The security page describes each one in longer form.

• Isolation between customers by three independent mechanisms: a data access layer with the workspace bound at construction so no query can be issued without it, compound foreign keys on the row and the workspace together so a cross-workspace row is a database error, and build guards that fail the build if either is bypassed.
• Storage minimisation by construction. Only the projection set defined in section 2 is persisted.
• Hidden by default. A new view publishes no attributes until the publisher switches each one on, and the exposure preview renders the real page before publication.
• Server-enforced field permissions. Only attributes marked visible are ever serialized to a viewer, and only attributes marked editable can be the subject of a proposed edit. Both are enforced on the server; the browser is not trusted.
• Approval before any write. No viewer action changes a record in Attio without a publisher approving it, and the attribute is re-read immediately before the write so a value that moved is not written over.
• Encryption. In transit over TLS. At rest by the database provider, and Attio access tokens additionally enveloped with AES-256-GCM under a rotatable key.
• Credential handling. Sign-in link tokens are stored only as SHA-256 hashes and consumed once atomically. Viewer IP addresses are stored hashed.
• Log hygiene. The logger serializes through an allowlist of key names, so an unrecognised key is dropped rather than printed, and passing record values to a log call fails the build.
• Auditability. Changes to what is published, and every edit, are recorded with a timestamp and, on gated views, the viewer’s verified email address.
• Revocability. Published pages are never held in a shared cache, so pausing or unpublishing takes effect on the next request rather than propagating.
• Fail-closed defaults. A filter that fails to compile issues no queries. An access mode a plan no longer permits becomes more restrictive, never open.

What we do not have, stated here rather than left for a questionnaire to discover: no SOC 2, no ISO 27001, no third-party penetration test, no single sign-on for publisher accounts, and no EU data residency.

6. Subprocessors

The publisher gives general authorisation for the subprocessors listed on the subprocessors page, which names each vendor, what it does, and what it can reach. Each is bound by terms no less protective than these.

We will give notice before adding or replacing one, and a publisher may object on reasonable data protection grounds; if we cannot resolve the objection, the publisher may terminate the affected service and be refunded for the unused period.

7. International transfers

Processing takes place in the United States. The database is hosted on Neon in AWS us-east-2 (Ohio), and the other subprocessors are US-based.

A publisher transferring personal data from the EEA, the UK or Switzerland therefore needs a transfer mechanism. The standard contractual clauses and the UK addendum have not been prepared or executed. This is one of the open items below and is the single most likely reason a reviewer will send this document back.

8. Retention and deletion

• Cached records: for as long as a published view needs them.
• Viewer sessions: short-lived, and revoked when a view is paused or its policy changes.
• Sign-in links: 15 minutes, single use.
• Analytics and the per-viewer access log: the plan’s retention, currently 30 days on Free, 12 months on Pro, 24 months on Business.
• Records of deleted items: 30 days.

On deletion of a view, the cached records for its source are purged unless another view still needs them. On disconnection of a workspace, every cached record from it is purged and the stored token is overwritten. On deletion of an account, the deletion cascades through every table carrying that workspace identifier, followed by a check that queries for any remaining row. Deletion completes without operator intervention, which is a design requirement because a controller’s erasure obligation cannot depend on our availability.

9. Assisting the controller

• Data subject requests. If one reaches us for data we process on a publisher’s behalf, we will pass it to that publisher rather than answer it, and help them respond. Deleting a view or an account is self-service, so an erasure request does not queue behind us.
• Impact assessments. We will supply the information we hold about the processing, which is largely this page and the security page.
• Personal data breaches. We will notify affected publishers without undue delay after becoming aware, with what we know at the time, what we are doing, and what we recommend. We will not wait for a complete picture before telling you something happened.

10. Audit

We will make available the information reasonably needed to demonstrate compliance with this agreement, and will contribute to an audit by the controller or an auditor they appoint, on reasonable notice and no more than once a year unless a regulator requires otherwise. There is no third-party audit report to substitute for this today, which is the honest state of a pre-launch product.

11. Getting a signed copy

A signed DPA is offered on the Business and Enterprise plans, and a custom one on Enterprise. Ask at help@publicviews.app and we will send what exists. Right now what exists is this draft, and we would rather you knew that before you asked.

12. What is still missing

• Standard contractual clauses, module selection, and the UK international data transfer addendum.
• The transfer impact assessment that goes with them.
• Governing law, venue, and the liability position between this agreement and the terms.
• The exact legal entity name, company number and registered address of the processor.
• Whether an EU or UK representative, or a data protection officer, must be appointed.
• The notice period for a subprocessor change, which should be a number rather than the word notice.
• A signature mechanism, and whether Business customers self-serve a counter-signed copy.

Until a lawyer completes those, this document describes the arrangement accurately and binds nobody.