This Data Processing Agreement ("DPA") forms part of the Terms of Service ("Agreement") between the customer ("Customer") and Document Blueprint, Inc. ("Document Blueprint", "we", "us"). It applies whenever Document Blueprint Processes Personal Data on Customer's behalf in connection with the Service. To the extent of any conflict, this DPA controls over the Agreement on matters of data protection.
This DPA becomes effective when Customer accepts it through the Settings → Enterprise flow in the Service. Acceptance binds Customer's organization, represented by the named signatory.
Terms not defined here have the meaning given in the Agreement.
GDPR terms map to CCPA terms as follows: Customer is the "Controller" under the GDPR / "Business" under the CCPA; Document Blueprint is the "Processor" under the GDPR / "Service Provider" under the CCPA.
Customer engages Document Blueprint to Process Personal Data only as necessary to provide the Service. Customer is the Controller / Business with respect to its Personal Data; Document Blueprint is the Processor / Service Provider acting on Customer's documented instructions, including those reflected in the Agreement, this DPA, and Customer's configuration of the Service (such as access controls, retention settings, and team membership).
Customer represents and warrants that:
Document Blueprint will:
Customer authorizes Document Blueprint to engage the Sub-processors listed at https://documentblueprint.com/legal/subprocessors. Document Blueprint will:
Document Blueprint will assist Customer in fulfilling Customer's obligation to respond to requests from Data Subjects under applicable law. The Service provides administrative tools that Customer may use to access, correct, export, or delete Personal Data within Customer's account. Where additional assistance is required, Customer may contact privacy@documentblueprint.com, and Document Blueprint will respond within a reasonable time given the nature of the request and the information available to Document Blueprint.
Document Blueprint will notify Customer of a Personal Data Breach without undue delay and, where feasible, within 72 hours of becoming aware of it. The notification will include, to the extent known at the time:
Document Blueprint will provide additional information as it becomes available. Document Blueprint's notification of a Personal Data Breach is not an admission of fault or liability.
On termination of the Agreement, meaning the end of the Customer's account under the Terms of Service (not the cancellation of a subscription, which moves the account to the Free plan with its data intact), Customer may export Customer Data through the Service's export tools under Settings or by request to support@documentblueprint.com. Following Customer's election, and in any event within 30 days of termination, Document Blueprint will delete or anonymize Customer Data, except to the extent retention is required by applicable law or for legitimate business purposes (such as resolving disputes or enforcing the Agreement). Document Blueprint retains no backup copies of Customer Data, so no deletion is deferred to a backup-retention schedule. Deleted records remain readable for up to one hour in the datastore's default version-retention window before they become unrecoverable. The product event records described in Annex II are not yet reached by this deletion process.
Customer may, on at least 30 days' prior written notice and no more than once per calendar year (except in cases of suspected non-compliance or following a Personal Data Breach), request Document Blueprint's then-current security documentation, which Document Blueprint will provide subject to confidentiality obligations. Customer may also conduct or commission an audit by a mutually agreed third-party auditor, subject to reasonable scope, timing, confidentiality, and cost-sharing terms. Customer is responsible for any costs Document Blueprint reasonably incurs in supporting an audit beyond the standard documentation request.
Where Document Blueprint Processes Personal Data of Data Subjects in the European Economic Area, the United Kingdom, or Switzerland, and that Processing involves a transfer of Personal Data outside those jurisdictions, the transfer is subject to:
Where Document Blueprint Processes Personal Information of California consumers on Customer's behalf:
Liability under this DPA is subject to the limitations of liability set forth in the Agreement. Nothing in this DPA creates additional liability beyond what is provided in the Agreement.
This DPA is effective on Customer's acceptance through the Service and remains in effect for the term of the Agreement. Termination of the Agreement automatically terminates this DPA. Sections that by their nature survive termination (including Sections 4, 7, 8, 9, 10, 11, and 12) will survive, as does the confidentiality obligation reflected in Annex II.
If any provision of this DPA is held to be invalid, illegal, or unenforceable, the remaining provisions remain in full force and effect. This DPA is governed by the laws specified in the Agreement, except to the extent applicable data protection law requires otherwise. Document Blueprint may modify this DPA by publishing an updated version at https://documentblueprint.com/legal/dpa. Material changes will be communicated to Customer at least 30 days before the effective date. Customer's continued use of the Service after the effective date of a modified DPA constitutes acceptance of the modified DPA, except to the extent the modification requires renewed signatory acceptance via the Settings → Enterprise flow.
Subject matter of the Processing: Provision of the Service described in the Agreement.
Duration of the Processing: The term of the Agreement, plus any post-termination retention period required under Section 8.
Nature and purpose of the Processing: Storage, retrieval, transformation, and AI-assisted extraction of Customer Data to support Customer's document workflows, automation, and reporting. This includes generating filled documents from Customer-provided templates, extracting structured values from Customer-provided files, and routing files into cases based on Customer-defined automations.
Categories of Data Subjects whose Personal Data is processed: Customer's end users, employees, clients, contacts, contractors, and any other individuals whose Personal Data is included in Customer Data.
Categories of Personal Data Processed:
Special Categories of Personal Data: Customer agrees not to submit special-category Personal Data (such as health data, biometric data, or data revealing racial or ethnic origin) unless a separate written agreement specifically permits such Processing.
This Annex describes the technical and organizational measures Document Blueprint has in place as of the version date above, in specific rather than generic terms. Where a measure that a security reviewer would commonly expect is not in place, this Annex says so rather than omitting it.
Scope and scale. Document Blueprint is operated by one individual, who holds the only standing administrative access to production systems. No other individual, whether employee or contractor, holds access to Customer Data. Access by Sub-processors is described in Section 5 and Annex III. Because the operating team is one person, Document Blueprint does not operate separation of duties, an access request and approval workflow, or periodic access reviews. The measures below are calibrated to that scale and to the nature of the Processing, and this Annex is updated when the answer changes.
Encryption. Personal Data is encrypted in transit using TLS 1.2 or higher, and encrypted at rest by Google Cloud using Google-managed keys, both in the datastore and in file storage. Document Blueprint does not currently apply any additional application-level encryption, and no field or document is encrypted under a Customer-specific key. The Service does not currently provide a way for a Customer administrator to designate fields as elevated-risk, so no field is treated as elevated-risk today.
Protection of data in transit. All connections to the Service use HTTPS. The application sends HTTP Strict Transport Security with a one-year max-age including subdomains, a Content Security Policy, X-Content-Type-Options nosniff, X-Frame-Options DENY with frame-ancestors 'none', a strict-origin-when-cross-origin referrer policy, and a permissions policy denying camera, microphone, payment, and USB access. These headers are asserted by an automated test, so a change that weakens them fails the build.
Data location. Customer Data is stored in the United States. Datastore records are held in Google's nam5 multi-region, which Google replicates across separate United States regions. Files are held in Google Cloud Storage and the application runs on Google Cloud Run in the us-east4 region. Document Blueprint does not offer a European or United Kingdom storage location. Sub-processor locations are stated in Annex III.
Separation between Customer accounts. Customer Data is stored under a path keyed to the owning account, and datastore and file-storage security rules deny access by default and grant it only where the requesting identity matches that path. The rules are the enforcement boundary rather than application code, so a request that bypasses the application cannot read another Customer's data. Both rule sets are covered by automated tests that run against the Firestore and Cloud Storage emulators on every push to the main branch and every pull request.
Authentication and authorization. End users sign in through Firebase Authentication, using Google sign-in or email and password. The browser session is carried by a Secure, HttpOnly cookie with a five-day lifetime. Every server action and every API route is declared through a single factory that applies authentication, a capability check where one is required, and a rate limit before the handler runs, so an unauthenticated or over-privileged request is rejected in one place rather than per endpoint. Team roles map to a capability table resolved per organization member and enforced on the server. Document Blueprint does not itself operate a second authentication factor. Where a Customer's users sign in with Google, that Customer's own identity provider policy, including any multi-factor requirement it enforces, applies to that sign-in.
Session termination. Signing out deletes the browser's copy of the session cookie. Document Blueprint does not currently revoke sessions on the server, so a session cookie copied before sign-out remains valid until it expires, for at most five days.
Customer-configurable access controls. Customer administers access within the Service: workspace ownership, team roles, invitation of individual collaborators to a case, and per-field and per-category visibility. Access is least privileged by configuration: a teammate can be restricted to named workspaces and to cases they are assigned to, and those restrictions are enforced in the datastore and file-storage security rules, not only in the interface. Category and field visibility is applied on the server before data is returned to portal users outside Customer's organization. For Customer's own teammates the same resolver is applied in the application, while the security rules independently control which whole cases that teammate may read; the rules do not filter individual fields within a case a teammate is already permitted to read, so field-level visibility should be treated as a presentation control for teammates and as a server boundary for portal users. Removal of a teammate's access takes effect immediately when Customer deactivates them, rather than at the next review.
Rate limiting and abuse controls. Every server action declares a rate limit at compile time against a central registry, and a missing declaration is a compilation error rather than an unlimited endpoint. Limits are enforced by an in-process bucket and a shared datastore counter. Application traffic is attested by Firebase App Check, which is not applied to the sign-in routes, the payment webhook, or the OAuth callbacks. Per-account AI usage quotas refuse further AI processing at zero remaining headroom, in both the web runtime and the background job runtime.
Personnel access to production. The Service contains no support screen, impersonation feature, or sign-in-as function through which Document Blueprint can read a Customer's cases, documents, or field values. The administrative surface is disabled in production, where every route under it returns not found. It is available only when Document Blueprint runs the application locally, and it exposes configuration and seeding controls rather than a view of Customer cases, documents, or field values. Access to Customer Data therefore requires direct use of the Google Cloud credentials for the production project, and is exercised only where necessary to operate the Service, to provide support, or to respond to an incident. Access to the production project is authorized through Google Cloud Identity and Access Management and authenticated by Google account sign-in. Access to the production project and to the source repository that deploys it is protected by a second authentication factor on the accounts through which that access is exercised. Administrative actions on the production project are recorded in Google Cloud Admin Activity audit logs, which cannot be disabled.
Personnel. Document Blueprint has no employees and no contractors. As the sole individual authorized to Process Personal Data, the operator is subject to the confidentiality obligations Document Blueprint owes Customer under this DPA, which is how the requirement in Article 28(3)(b) GDPR is met at this scale. Document Blueprint conducts no background checks and operates no personnel screening or security awareness training, because there are no personnel to whom either would apply. Before any additional person is given access to production systems or Customer Data, that person will sign a written confidentiality undertaking covering all Customer Data, will receive only the access their work requires, and will lose that access when it is no longer needed, and this Annex will be updated. Personnel of the Sub-processors identified under Annex III are screened under those Sub-processors' own employment and compliance policies; Document Blueprint imposes equivalent confidentiality obligations on them by contract under Section 5 and remains responsible for their acts and omissions.
Credential and secret handling. Production services authenticate as Google-managed service-account identities and take credentials from the runtime environment. No static service-account private key is configured for production. Third-party API keys and other production secrets are held in Google Secret Manager and referenced by name from the deployment configuration, so no secret value is stored in the source repository. Every push to the main branch and every pull request runs an automated secret scan across the full repository history. Production is built and deployed only from the production branch of the connected source repository, so control of that repository is a production access path.
AI processing. Document Blueprint uses one AI provider, Google, for document extraction and template fill. The Google services that receive Customer Data for this purpose are identified in Annex III, and Google's handling of prompts and responses is governed by the terms linked there. Document Blueprint stores no separate copy of a prompt; what is retained is the extracted values written into the Customer's case. Customer Data is not sent to any other AI provider. Extraction prompts instruct the model to treat document content as data rather than as instructions.
Outbound request controls. The Service does not fetch arbitrary destinations supplied by a Customer or contained in a document. Outbound fetches are restricted by host allowlists with redirect, size, and scheme checks, covered by automated tests. The two runtimes are not equivalent: the background-processing allowlist performs fewer checks than the application allowlist.
Integrity of outbound communications. User-supplied content interpolated into outbound email passes through a single canonical escaper, so content held in a case cannot inject markup into an email Document Blueprint sends.
Logging. Google Cloud Logging collects the Service's application logs, a request log entry for every request served, and function execution logs, automatically and without configuration by Document Blueprint. A request log entry records the caller IP address, user agent, requested URL, response status, and timestamp. Application log lines are structured and carry the trace of the request that produced them, so the sequence of authenticated operations performed during a request can be reconstructed for the retention period, even though individual datastore reads are not separately recorded. These entries are retained for 30 days, and Google Cloud Admin Activity audit logs, which record configuration changes to the infrastructure itself, are retained for 400 days. Both periods are Google Cloud defaults that Document Blueprint has not altered. Google Cloud Data Access audit logs, which would record an individual read or write of a Customer record in the datastore, are disabled by default and have not been enabled, so individual reads of Customer Data are not logged.
Records within the Service. Defined case events, including file ingestion, template runs, collaborator changes, mailbox moves, identifier renames, and file moves and deletions, are written to that case's activity history with the acting user and a timestamp. Separately, each field value carries its own history entry recording the value, the time it was set, and the source that set it. Customer can read both in the application. Legal acceptance events and portal signing events are recorded with the signer's identity, IP address, user agent, and timestamps, and signing records additionally carry document hashes that make later alteration detectable; these records are retained for seven years. Document Blueprint also records product events, including sign-in, sign-up, and tracked actions, against the account's user identifier. Those records contain no IP address and no user agent. They are not currently pruned on a schedule and are not yet reached by the account deletion process described in Section 8.
Monitoring and detection. Collection of logs and metrics by Google Cloud is continuous and automatic. Review of them is not. Document Blueprint does not operate a security information and event management system, an intrusion detection system, automated security alerting, or a third-party security monitoring service, and there is no on-call rotation. No rule detects anomalous access to Customer Data. Automated protection is preventive rather than detective: the rate limits, usage quotas, and traffic attestation described above act without an operator being present. Documented checks, including the checks for failed AI usage metering, are performed by an operator following a written runbook that names the exact signals to look for, rather than by an automated rule. An incident is identified when the operator reviews Google Cloud logs, billing and usage dashboards, and provider dashboards, or when a Customer reports one.
Incident response. Document Blueprint maintains a written incident-response runbook covering triage, containment, investigation, credential rotation, and post-incident review. It is written for service-abuse and cost incidents; a Personal Data Breach is handled under Section 7 of this DPA. Containment controls are enforced on the server at the point of use: switches that disable AI processing, transactional email, payment webhook processing, and new account signups, and a read-only mode that rejects mutating API routes and server actions. The web runtime honors every switch within about fifteen seconds; the background job runtime independently honors the AI and email switches on the same interval. In production these switches are changed by an operator with authenticated access to the production Google Cloud project, because the administrative screen that presents them is built only into development environments. Investigation draws on Google Cloud logs, payment webhook event records, per-account AI usage records, and the Service's own event records. Customer, or a Customer's user who suspects unauthorized access, should report it to privacy@documentblueprint.com. Notification of a Personal Data Breach follows Section 7, and the 72 hour period runs from the point Document Blueprint becomes aware.
Availability and resilience. Datastore records are replicated by Google across separate United States regions, and across zones within each region, so they continue to be served through the loss of an entire region. Files rely on the same underlying durability and replication in Google Cloud Storage. Availability and redundancy at that layer are provided by Google Cloud. Document Blueprint operates a single production environment, has no failover to a second provider, and gives no uptime commitment in this Annex.
Restoration after an incident. Document Blueprint does not operate a scheduled backup of Customer Data and retains no backup copies. Firestore Point-in-Time Recovery is not enabled on the production database, so recoverable history is limited to the one hour of prior document versions the datastore retains by default; that window can be read at a past timestamp but cannot be exported or cloned. The replication described above protects against infrastructure failure. It does not protect against deletion or corruption by the application or by a Customer, which is what a backup protects against. There is no separate disaster recovery plan and no tested restore procedure. Customer can export Customer Data at any time as described below, and should keep an independent copy of records it cannot reproduce.
Data minimization and pseudonymization. Document Blueprint collects only the Personal Data necessary to provide the Service. Card details pass from the payer's browser to the payment Sub-processor and never reach Document Blueprint's systems. Several Sub-processors identified in Annex III receive no Customer Data at all. Document Blueprint does not pseudonymize Personal Data: Customer Data is stored in the form Customer submits it, because the extraction and document-generation features operate on the original values. Article 32(1)(a) GDPR names pseudonymization as a measure to consider, and this Annex records that it is not used.
Data portability and erasure. Customer can download a structured export of its workspaces, templates, and cases from Settings, on any plan and without connecting a third-party account, and can copy the underlying files to Customer's own Google Drive by connecting one. Deleted cases are purged automatically 30 days after deletion. Inactive free accounts are deleted by a nightly sweep after the notice and recovery period described in the Data Retention Policy. Deletion following workspace or account termination is performed by the operator within the period stated in Section 8 rather than by a scheduled job, and the Service provides no self-service account deletion control. Some root-level records, including the product event records described above, are not yet reached by the automated purge.
Retention. Retention periods for each category of data, and which of them are enforced automatically rather than by manual operation, are published at https://documentblueprint.com/legal/retention. That page is the operative retention schedule for this Annex.
Testing and evaluation of effectiveness. Every change runs an automated suite on every push to the main branch and every pull request: linting, type checking, unit tests, security rules tests executed against the Firestore and Cloud Storage emulators, and the secret scan described above. This is the process referred to in Article 32(1)(d) GDPR. It is automated testing rather than independent assessment: Document Blueprint has commissioned no third-party penetration test and no external audit of these measures.
Accountability. Document Blueprint maintains an internal control register recording, for every commitment made in its published policies, the mechanism that keeps it, the file where that mechanism is enforced, the test that proves it, and a status of enforced, partial, or unenforced. An automated test asserts that every enforcement path named in the register still exists, so removing a control fails the build rather than quietly turning a published sentence into a false one. Entries recorded as partial or unenforced are tracked as open gaps rather than presented as controls.
Vendor management. Document Blueprint has no separate vendor security review function. A Sub-processor is selected for its function, and Document Blueprint relies on that vendor's published security documentation and published data processing terms rather than on an assessment, questionnaire, or audit of its own. Each Sub-processor that Processes Personal Data on Document Blueprint's behalf is bound by the data processing terms forming part of its own standard customer agreement, linked from Annex III. Google's Cloud Data Processing Addendum is incorporated into the Google Cloud and Firebase agreements without separate signature and governs the Google Cloud services identified in Annex III. The Gemini API is governed by Google's Data Processing Addendum for Products Where Google is a Data Processor. Google Maps Platform and Google Analytics operate under Google's controller-to-controller terms, under which Google acts as an independent controller rather than as a Sub-processor. Document Blueprint negotiates no bespoke terms with any Sub-processor and audits no Sub-processor. Annex III states, for each Sub-processor, the categories of data it receives and where it is hosted. Annex III is revised when a Sub-processor is added or replaced, and is reconciled against the services the Service actually calls during a compliance review; the most recent reconciliation was performed in September 2026. There is no fixed calendar cadence for that reconciliation. Customer receives the notice described in Section 5 before a Sub-processor that Processes Personal Data is added or replaced, and Document Blueprint remains liable to Customer for the acts and omissions of its Sub-processors.
Physical and environmental security. Document Blueprint operates no data centers and owns no production hardware. All Customer Data is held in Google Cloud facilities, and physical and environmental controls at those facilities are provided by Google as a Sub-processor.
Certification and independent assurance. Google LLC holds ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and SOC 2 Type II for the Google Cloud infrastructure on which the Service runs. Those certifications cover Google's infrastructure and do not extend to Document Blueprint's application, its code, or its operations. Document Blueprint holds no security certification of its own, has not completed a SOC 2 examination, and has not commissioned a third-party penetration test. A Customer requiring a certification held by Document Blueprint itself should treat that as unavailable.
Reporting a security issue. A suspected vulnerability or unauthorized access can be reported to privacy@documentblueprint.com. Reports are triaged by the operator. There is no continuous response rotation and no bug bounty.
Measures not in place. So that a reviewer does not have to infer them, the following are not implemented. Multi-factor authentication is not offered by the Service to Customer's own users, who sign in through Firebase Authentication. Where a Customer's users sign in with Google, that Customer's own identity provider policy applies to that sign-in. There is no intrusion detection, no security information and event management tooling, and no automated security alerting. Individual reads of Customer Data are not logged. There is no scheduled backup and no tested restore procedure. Server-side session revocation is not implemented. There is no automated dependency vulnerability scanning. There is no personnel screening, security awareness training, or offboarding revocation process, because there are no personnel. Document Blueprint holds no security certification and has commissioned no penetration test. This Annex is updated as these change.
The current list of Sub-processors is maintained at https://documentblueprint.com/legal/subprocessors. Customer is notified of changes per Section 5.