AttestLayer

AttestLayer Policy

Data Processing Addendum

This root-domain page explains how AttestLayer handles baseline processor terms across its first-party surfaces and how to request an executed DPA. The root site itself is primarily an informational controller-operated surface.

Updated 18 April 2026 Canonical root-domain policy

What this public DPA page is for

The root domain publishes AttestLayer's baseline processor posture and routes customers to the surface-specific DPA that matches the workflow they are using.

attestlayer.com itself is mostly a controller-operated corporate and trust site. Processor terms usually matter on the direct-buyer or partner workflow surfaces where a customer submits materials for processing.

Roles by surface

Surface Typical role Notes
attestlayer.com root site AttestLayer is controller Covers website usage, inquiries, and trust or corporate communications on the root domain.
buy.attestlayer.com direct-buyer workflows Customer is controller or business; AttestLayer is processor or service provider for submitted workflow material AttestLayer remains controller for its own account, billing, fraud, security, and legal-compliance data.
partners.attestlayer.com and approved partner-console access Partner is controller or business; AttestLayer is processor or service provider for submitted workflow material The partner remains responsible for downstream notice and authority where it acts on behalf of its own customer.
verify.attestlayer.com and registry.attestlayer.com Separate public utility notices apply These surfaces are public verification and registry utilities, not private upload surfaces for regulated workflow content.
pay.attestlayer.com redirect External payment surface Payment-processor notices and the governing direct-buyer terms control the checkout step completed there.

Baseline processor commitments

Where AttestLayer acts as a processor or service provider on a first-party workflow surface, the baseline commitments are consistent across standard agreements unless a negotiated document says otherwise.

  • Process customer workflow data only on documented instructions embodied in the applicable surface, order, or signed agreement.
  • Limit personnel access to the roles that need it and bind those roles to confidentiality obligations.
  • Use technical and organizational measures appropriate to a cloud-native, record-only workflow.
  • Use subprocessors that are contractually bound to support the service, with the current list published on the applicable subprocessor page.
  • Support reasonable requests for deletion, return, access, or security-incident coordination as required by the governing agreement or law.