Data Processing Addendum

This Data Processing Addendum ("DPA") is part of the Master Subscription Agreement (pitchlume.ai/legal/terms) or other agreement (the "Agreement") between EraShift Studio LLC ("EraShift") and Customer. It applies when EraShift processes Customer Personal Data in providing the Service. If this DPA conflicts with the Agreement on the processing of personal information, this DPA controls (Agreement §26.2).

1. Definitions

1.1 "Data Protection Laws" means all US federal and state laws on the privacy and security of personal information that apply to the processing of Customer Personal Data under the Agreement, including the California Consumer Privacy Act as amended by the California Privacy Rights Act and its regulations ("CCPA"), the Texas Data Privacy and Security Act ("TDPSA"), the Virginia Consumer Data Protection Act, the Colorado Privacy Act, the Connecticut Data Privacy Act, and similar comprehensive state privacy laws, each as amended.

1.2 "Customer Personal Data" means personal information, personal data or similar information as defined by Data Protection Laws that is contained in Customer Data and that EraShift processes on Customer's behalf under the Agreement.

1.3 "Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data in EraShift's or its Subprocessors' systems. It does not include unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, such as pings, port scans, blocked sign-in attempts or denial-of-service attacks.

1.4 "Subprocessor" means a third party that EraShift engages to process Customer Personal Data in providing the Service. Third-Party Services that Customer enables (for example Customer's own CRM, visitor identification service or sending domain) are not Subprocessors.

1.5 "Consumer", "business", "service provider", "contractor", "controller", "processor", "sell", "share", "business purpose", "deidentified" and "sensitive personal information" have the meanings given in the applicable Data Protection Laws. Other capitalized terms have the meanings in the Agreement.

2. Roles and scope

2.1 Roles. For Customer Personal Data, Customer is the business or controller, and EraShift is the service provider, contractor or processor, as those terms apply under each Data Protection Law.

2.2 EraShift as an independent business. EraShift processes some personal information for its own purposes as a business or controller, under its Privacy Policy at pitchlume.ai/legal/privacy, and not under this DPA. This covers: account and contact details of Customer's billing and administrative contacts; website forms; and data EraShift needs to run its business (billing, sales, legal compliance). To the extent Data Protection Laws permit a service provider to use personal information for internal purposes (for example under 11 CCR §7050(a)), EraShift may use Customer Personal Data to: build and improve the quality of the Service (without building or modifying a profile of a Consumer for another business, and without training AI models on Customer Content, Agreement §13.7); detect and prevent security incidents, fraud and illegal activity; debug and repair errors; and comply with law.

2.3 Details of processing. Annex 1 describes the subject matter, nature, purpose and duration of the processing, the types of Customer Personal Data and the categories of Consumers.

2.4 US law only. This DPA is written for United States law. The Service is offered to businesses in the United States. Customer will not use the Service to process personal data that is subject to the EU or UK General Data Protection Regulation, or to another non-US data protection law that requires additional contract terms, unless the parties first sign those terms.

2.5 No health or payment card data. EraShift is not a business associate under HIPAA and does not sign business associate agreements. Customer will not submit protected health information or payment card numbers to the Service.

3. Customer's instructions and EraShift's obligations

3.1 Instructions. EraShift will process Customer Personal Data only to provide, secure and support the Service under the Agreement, and on Customer's documented instructions. The Agreement, this DPA, and Customer's configuration and use of the Service (including actions by its Workspace admins and Authorized Users) are Customer's complete instructions. Additional instructions require written agreement. EraShift will tell Customer if, in its opinion, an instruction violates Data Protection Laws, and may then decline to follow it.

3.2 Business purposes. Customer discloses Customer Personal Data to EraShift only for the limited and specified business purposes of providing the Service described in the Agreement and Annex 1.

3.3 CCPA service provider and contractor terms. EraShift will not:

(a) sell or share Customer Personal Data;

(b) retain, use or disclose Customer Personal Data for any purpose (including any commercial purpose) other than the business purposes in the Agreement and this DPA, or as otherwise permitted for service providers and contractors by the CCPA;

(c) retain, use or disclose Customer Personal Data outside the direct business relationship between EraShift and Customer; or

(d) combine Customer Personal Data with personal information it receives from or on behalf of another person, or collects from its own interactions with a Consumer, except as the CCPA permits for a business purpose.

3.4 Compliance and notice. EraShift will comply with the obligations that Data Protection Laws impose on it as a service provider, contractor or processor, and will provide the same level of privacy protection the CCPA requires of businesses. EraShift will notify Customer if it determines that it can no longer meet its obligations under Data Protection Laws.

3.5 Customer's rights to take steps. Customer may take reasonable and appropriate steps to make sure EraShift uses Customer Personal Data consistently with Customer's obligations under Data Protection Laws (for example through Section 9), and, on notice, to stop and remediate unauthorized use of Customer Personal Data.

3.6 Deidentified data. If EraShift receives deidentified data from Customer, or creates Usage Data from Customer Personal Data, EraShift will: (a) take reasonable measures to make sure it cannot be associated with a Consumer or household; (b) publicly commit to maintain and use it only in deidentified form and not attempt to re-identify it; and (c) contractually require any recipient to do the same.

3.7 Certification. EraShift certifies that it understands the restrictions in this Section 3 and will comply with them.

3.8 Customer's responsibilities. Customer is responsible for: (a) the lawfulness of its collection of Customer Personal Data and of its instructions; (b) giving the notices and getting the consents Data Protection Laws require, including for contact records in its CRM, visitor identification it enables, email it sends, and meeting recordings it uploads; (c) not providing sensitive personal information or Restricted Data (Agreement §5 and the Restricted Data Policy); and (d) the security of its own accounts and configuration.

4. Confidentiality of personnel

4.1 EraShift will make sure that each person it authorizes to process Customer Personal Data (including employees, contractors and Subprocessors) is subject to a duty of confidentiality, by contract or law, and processes it only as this DPA permits.

4.2 EraShift limits personnel access to Customer Personal Data to those who need it to provide, secure and support the Service, and records the changes its administrative console makes to a Workspace.

5. Subprocessors

5.1 Authorization. Customer gives EraShift general authorization to engage Subprocessors. The current Subprocessors are listed at pitchlume.ai/legal/subprocessors and summarized in Annex 3.

5.2 Contracts. EraShift will enter into a written contract with each Subprocessor that imposes data protection obligations no less protective than this DPA, to the extent appropriate to the service it provides, and that meets the requirements of Data Protection Laws for subcontracting. EraShift remains responsible to Customer for its Subprocessors' performance of those obligations.

5.3 Notice of new Subprocessors. EraShift will give at least 30 days' notice before a new Subprocessor begins processing Customer Personal Data, by updating the Subprocessor List and notifying Customer's notice contact or Workspace admins by email. In an emergency (for example to keep the Service secure or available), EraShift may give shorter notice, and will give notice as soon as practicable.

5.4 Objection. Customer may object to a new Subprocessor on reasonable data protection grounds by notice to info@pitchlume.ai within the notice period. The parties will discuss the objection in good faith. EraShift may offer a reasonable alternative (for example not using the Subprocessor for Customer's Workspace, or turning off the affected feature). If the parties cannot resolve the objection within 30 days, Customer may terminate the affected part of the Service by notice, and EraShift will refund prepaid Fees for the terminated part for the remainder of the Subscription Term. This is Customer's sole remedy for an objection.

6. Security

6.1 Measures. EraShift will implement and maintain appropriate technical and organizational measures to protect Customer Personal Data, taking into account the nature of the processing and the risks, including the measures in Annex 2. EraShift may update those measures, but will not materially reduce the overall level of protection during a Subscription Term.

6.2 Assessments. EraShift will give Customer reasonable information it needs to carry out data protection assessments that Data Protection Laws require of it, to the extent Customer does not otherwise have that information.

7. Consumer requests

7.1 Assistance. Taking into account the nature of the processing, EraShift will give Customer reasonable assistance, through the features of the Service or otherwise, to respond to Consumer requests to exercise their rights under Data Protection Laws (for example access, correction, deletion, portability, and opt-outs).

7.2 Current tools. Workspace admins can view, edit and delete much of Customer Personal Data in the Service (for example member accounts, contact records and files). Self-service export and deletion of an individual's data are not available yet; EraShift handles those requests manually. Customer may send them to info@pitchlume.ai, and EraShift will respond within 10 business days with the requested assistance.

7.3 Requests sent to EraShift. If EraShift receives a Consumer request that concerns Customer Personal Data, EraShift will not respond to the Consumer (except to tell them to contact Customer, or as required by law) and will forward the request to Customer within 5 business days, where it can identify Customer.

8. Security Incidents

8.1 Notice. EraShift will notify Customer without undue delay, and in any event within 72 hours after confirming a Security Incident affecting Customer Personal Data, or sooner where a law that applies to EraShift requires it.

8.2 Content. The notice will describe, to the extent known: the nature of the Security Incident; the categories and approximate number of Consumers and records affected; the likely consequences; the measures taken or proposed; and a contact for more information. EraShift will update the notice as it learns more.

8.3 Cooperation. EraShift will take reasonable steps to contain, investigate and remediate the Security Incident, and will give Customer reasonable assistance to meet Customer's own obligations to notify Consumers, regulators or others. Unless the law requires otherwise, Customer decides whether and how to notify affected Consumers and regulators about Customer Personal Data, and EraShift will not notify them on Customer's behalf without Customer's consent, except where the law requires EraShift to.

8.4 No admission. EraShift's notice of, or response to, a Security Incident is not an admission of fault or liability.

8.5 Channel. Notices go to Customer's notice contact and Workspace admins. Customer can report suspected incidents to help@pitchlume.ai.

9. Audits and information

9.1 Information first. On written request, and no more than once in any 12-month period (unless after a Security Incident or at a regulator's request), EraShift will provide information reasonably needed to demonstrate its compliance with this DPA, in this order:

(a) EraShift's security documentation (including Annex 2 and the Security Overview at pitchlume.ai/legal/trust);

(b) written answers to a reasonable security questionnaire; and

(c) if and when available, a summary or copy of an independent third-party audit report, under confidentiality. EraShift has no such report today.

9.2 Assessments. If the information under Section 9.1 is not enough to demonstrate compliance with this DPA, or if Data Protection Laws require it, Customer (or a qualified, independent assessor Customer appoints that is bound by confidentiality and is not a competitor of EraShift) may carry out an assessment of EraShift's compliance with this DPA, on these terms:

(a) at least 30 days' written notice with a proposed scope;

(b) during US Central Time business hours, without unreasonable disruption to EraShift's business;

(c) remote by default; an on-site visit only if a remote assessment cannot reasonably meet the purpose;

(d) no access to other customers' data, EraShift's or Subprocessors' facilities beyond what EraShift controls, or information that would compromise security;

(e) at Customer's cost, including EraShift's reasonable time at its then-current professional services rate where the assessment takes more than 8 hours of EraShift personnel time; and

(f) no more than once in any 12-month period, except after a Security Incident or at a regulator's request.

9.3 Independent assessor (TDPSA and similar). Instead of a Customer assessment under Section 9.2, EraShift may arrange for a qualified and independent assessor, using an appropriate and accepted control standard, to assess its policies and technical and organizational measures, and give Customer the report on request.

9.4 Subprocessors. Audits of Subprocessors are met by the reports and information those Subprocessors make available (for example the hosting and database providers' own audit reports), which EraShift will share where it is allowed to.

10. Deletion and return

10.1 At the end. When the Agreement ends, EraShift will return and delete Customer Personal Data as the Agreement describes (Agreement §11): an export on request during a 30-day Export Window, then deletion from active systems within 90 days, with backup copies deleted on the hosting provider's normal backup cycle. EraShift's staff carry out export and deletion on request; there is no self-service tool yet.

10.2 Exceptions. EraShift may keep Customer Personal Data that the law requires it to keep, and records it keeps as a business under Section 2.2 (for example billing and security records), for as long as needed for those purposes. This DPA continues to apply to anything kept.

10.3 Certification. On request, EraShift will confirm deletion in writing.

11. Location of processing

11.1 United States. EraShift will store Customer Personal Data only in the United States, and will process it, and permit its Subprocessors to process it, only in the United States, except where the Subprocessor List states otherwise for a named, optional feature that Customer chooses to use, or where Customer agrees otherwise in writing.

12. Data Protection Law changes

12.1 If a change in Data Protection Laws requires a change to this DPA, the parties will negotiate in good faith to amend it. EraShift may update this DPA to reflect new legal requirements by notice under Agreement §26.4, if the update does not reduce Customer's protections.

13. Liability

13.1 Each party's liability under this DPA is subject to the limitations and exclusions in the Agreement (Agreement §18), including the Super-Cap for Data Breach Claims in Agreement §18.4.

14. Term

14.1 This DPA lasts as long as EraShift processes Customer Personal Data under the Agreement.

Annex 1: Details of processing

Annex 2: Security measures

This Annex describes the measures in place on the date above. Items marked Not yet are stated so that this Annex does not overstate EraShift's controls.

1. Hosting and location

• Hosted in the United States: database, authentication and file storage on Supabase (AWS us-west-2); application functions on Vercel in a US region (Oregon).

2. Workspace isolation and access control

• Each Workspace's data is separated by Postgres row-level security policies enforced in the database, deny by default. Automated tests check that one Workspace cannot read or change another's data.
• Role-based access within a Workspace, configured by Customer's admins. Downloads are off for non-admin users until an admin enables them.
• Calculation tables are read only by server functions that return one result at a time.
• EraShift platform administration runs through a separate, server-only service account; every platform write names the target Workspace and is audited. A platform administrator cannot enter a Workspace they are not a member of.

3. Authentication

• Password plus a 6-digit code sent by email on every new session; sessions last 12 hours; optional "remember this device" for 30 days with a token stored only as a hash.
• Sign-in codes are stored hashed, valid 10 minutes, deleted after 1 day.

4. Encryption

• In transit: TLS on every connection, HSTS (two years, including subdomains). Server-side database connections outside the app require TLS.
• At rest: storage and database encrypted by the provider (AES-256).
• Application-layer encryption for drawings and sealed PDFs, CAD and 3D files, exports, account files, meeting recordings and transcripts files, and catalog uploads: a per-Workspace data key (AES-256-GCM, envelope encryption) wrapped by a master key held outside the database.
• Not yet: customer-managed keys; end-to-end encryption (the server decrypts to render, watermark and serve files); application-layer encryption of database rows (for example transcript text and extracted values rely on disk encryption plus access controls).

5. Application security

• Enforced Content-Security-Policy with per-request nonces; framing blocked except for embeds on websites the Workspace allows.
• Files are served through an access-checked route with no-store caching.
• Keys, wrapped keys and file contents are never logged.

6. Logging, monitoring and watermarking

• Views, prints, exports and admin actions are logged with user, Workspace, time, IP address and user agent.
• Printed sealed drawings carry a watermark naming the Workspace, the person's company and the time. Exported files carry an embedded notice naming the Workspace, the time and an export ID. The audit trail records who made each print and export.
• Error monitoring with scrubbing (when configured); CSP reports stored after redaction for 30 days.

7. AI processing

• AI providers are US-based, on paid commercial terms that do not permit training on Customer Data. Drawings and customer files go only through direct provider accounts (OpenAI, Google Cloud Vertex AI, Anthropic) with zero data retention where offered; otherwise the call fails closed. Calls that carry no customer files may use the Vercel AI Gateway with no-training and zero-data-retention settings. Each AI job sees only its own Workspace's data.
• Before any AI call, code (not an AI model) checks uploads for restricted-data markings, and the uploader's declaration and any consent are recorded.
• Not yet: written confirmation of zero data retention from every AI provider (standard retention of up to 30 days for abuse monitoring applies until then).

8. Email

• Nothing emails Customer's customers or prospects automatically; people send. A platform switch can stop a Workspace's outbound email.

9. Backups and continuity

• Daily database backups by the hosting provider.
• Not yet: point-in-time recovery; a tested restore; a documented disaster recovery plan with targets.

10. People and process

• Personnel with access to Customer Data are bound by confidentiality; access is limited to need.
• Releases follow a documented process with typechecks, tests (including tenant isolation tests) and build checks.
• Not yet: formal written information security policies adopted, periodic access reviews, security awareness training records, an independent security audit of any kind.

11. Incident response

• Security reports to help@pitchlume.ai. Notice under Section 8. A public status page shows current service status.
• Not yet: a written incident response plan and tabletop test.

Annex 3: Subprocessors (reference)

The current list, which controls, is at pitchlume.ai/legal/subprocessors. As of November 13, 2026:

Not Subprocessors: Third-Party Services that Customer enables (for example Customer's CRM, visitor identification, and Customer's own sending domain), and services that receive no Customer Data (listed on the Subprocessor List).

Change log