Data Processing Agreement

1. Scope and acceptance

This Data Processing Agreement (the "DPA") is between the customer that accepts our Terms of Service ("Customer") and NMAJOR STUDIOS LLC, a Wyoming limited liability company ("NMajor Studios", "we" or "us"), doing business as Desktop Accounting API. It forms part of the Terms and applies automatically, without a signature, whenever we process Customer Personal Data while providing the Services. Customers that need a countersigned copy can request one through our contact page.

If this DPA conflicts with the Terms, this DPA controls for the processing of personal data. If it conflicts with the Standard Contractual Clauses, the Standard Contractual Clauses control.

2. Definitions

• Data Protection Laws means all laws on privacy and personal data that apply to the processing under this DPA, including the EU General Data Protection Regulation 2016/679 ("GDPR"), the GDPR as retained in UK law ("UK GDPR") and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection ("FADP"), and US state privacy laws such as the California Consumer Privacy Act as amended ("CCPA").
• Customer Personal Data means personal data in Customer Data, as defined in the Terms, that we process on Customer's behalf.
• Personal Data Breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data that we process.
• Standard Contractual Clauses or SCCs means the clauses annexed to European Commission Implementing Decision (EU) 2021/914.
• UK Addendum means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.
• "Controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings given in the GDPR. "Service provider", "contractor", "sell" and "share" have the meanings given in the CCPA.

3. Roles of the parties

Customer is the controller of Customer Personal Data, or a processor acting for its own customers (End Users) who are the controllers. We are Customer's processor or, where Customer is itself a processor, a subprocessor. Where Customer acts as a processor, Customer confirms that its controller has authorized Customer's instructions and our appointment, and Customer remains our sole point of contact.

We are an independent controller only of the account, billing, support and security data described in our Privacy Policy. This DPA does not apply to that data.

4. Processing on documented instructions

We process Customer Personal Data only on Customer's documented instructions, unless the law to which we are subject requires otherwise, in which case we will inform Customer before processing unless that law prohibits it. Customer's instructions are the Terms and this DPA, the API requests Customer's applications send, and the settings Customer chooses in the dashboard, such as payload capture and End User deletion. Additional instructions require our written agreement. We will tell Customer if, in our opinion, an instruction infringes Data Protection Laws.

5. Customer obligations

Customer is responsible for having a lawful basis for the processing, for giving data subjects the notices that the law requires, and for obtaining each End User's authorization before connecting its QuickBooks company file. Customer decides which data its applications request and should request only what it needs. Customer will not instruct us to process special categories of personal data unless that is necessary for its accounting purpose and permitted by law.

6. Confidentiality of personnel

We limit access to Customer Personal Data to personnel who need it to provide, secure or support the Services, and everyone with access is bound by an obligation of confidentiality.

7. Subprocessors

Customer gives general authorization for us to engage the subprocessors listed on our subprocessor page. Before we engage a subprocessor, we impose on it data-protection obligations that provide at least the same level of protection as this DPA, to the extent applicable to the service it provides. We remain responsible to Customer for our subprocessors' performance of those obligations.

We will update the subprocessor page at least 30 days before a new subprocessor begins processing Customer Personal Data, except in an emergency affecting the security or availability of the Services, when we will update it as soon as we can. Customer may object on reasonable data-protection grounds by contacting us within that period. We will then work in good faith on a reasonable alternative. If we cannot provide one within 30 days, Customer may terminate the affected Services by written notice, and we will not charge for billing periods after the termination.

8. Security

We implement and maintain the technical and organizational measures described in Annex 2, which are designed to protect Customer Personal Data against Personal Data Breaches and to ensure a level of security appropriate to the risk. We may update these measures as technology and threats change, provided the overall level of protection does not decrease.

9. Personal Data Breach notification

We will notify Customer without undue delay after becoming aware of a Personal Data Breach. We send the notice to the organization's owners by email and include, as soon as the information is available, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address it. Where we cannot provide all of this at once, we will provide it in stages without further undue delay.

We will take reasonable steps to contain and investigate the breach and to reduce its effects, and we will give Customer reasonable assistance with its own notification obligations. Our notice is not an acknowledgment of fault or liability.

10. Data subject requests

The API and dashboard let Customer retrieve, update and delete End User records and their connection data, and stored request data expires automatically under Annex 1. If we receive a request from a data subject about Customer Personal Data, we will not respond to it ourselves, except to direct the data subject to Customer, and we will forward it to Customer where we can identify Customer. Taking into account the nature of the processing, we will provide reasonable assistance to help Customer respond to requests to exercise data subject rights.

11. Impact assessments and consultations

Taking into account the nature of the processing and the information available to us, we will give Customer reasonable assistance with data protection impact assessments and prior consultations with supervisory authorities that Data Protection Laws require, mainly by providing the information in this DPA, our security page and our documentation.

12. Information and audits

We will make available the information reasonably necessary to demonstrate compliance with this DPA. We do this first through our published documentation, this DPA and our security page, and second by answering one written security questionnaire from Customer each year, or more often after a Personal Data Breach or at a supervisory authority's request.

If that information is not enough to demonstrate compliance, or a supervisory authority requires it, Customer may audit our compliance with this DPA, either itself or through an independent auditor bound by confidentiality. Customer must give at least 30 days' written notice, agree the scope and timing with us in advance, conduct the audit during business hours without disrupting the Services or accessing other customers' data, and bear its own costs. We do not hold third-party security certifications, and we will not grant physical access to facilities run by our infrastructure providers; we will instead provide the providers' own audit reports where they make them available to us.

13. International transfers

NMajor Studios is established in the United States, and Customer Personal Data may be processed in the countries listed on the subprocessor page. Where a transfer of Customer Personal Data to us is a restricted transfer under the GDPR, the UK GDPR or the FADP, the following safeguards are incorporated into this DPA by reference:

• EEA transfers: the Standard Contractual Clauses, Module Two (controller to processor) where Customer is a controller and Module Three (processor to processor) where Customer is a processor. Customer is the data exporter and NMAJOR STUDIOS LLC is the data importer. Clause 7 (docking clause) applies. Under Clause 9(a), Option 2 (general written authorization) applies, with the notice period in section 7 of this DPA. The optional wording in Clause 11 does not apply. Under Clause 13, the competent supervisory authority is the one determined by Customer's establishment or EU representative. Under Clauses 17 and 18, the governing law is the law of Ireland and disputes are resolved by the courts of Ireland. Annexes I and II of the SCCs are completed by Annexes 1 and 2 of this DPA, and Annex III by the subprocessor page.
• UK transfers: the UK Addendum, completed with the information above. In Table 4, either party may end the UK Addendum as set out in its Section 19.
• Swiss transfers: the SCCs as described for EEA transfers, with the Swiss Federal Data Protection and Information Commissioner as the competent supervisory authority, references to the GDPR read as references to the FADP, and "Member State" read to include Switzerland so that data subjects there can enforce their rights.

Where we engage a subprocessor that receives Customer Personal Data in a country without an adequacy decision, we rely on an appropriate transfer mechanism with that subprocessor.

14. Deletion and return

During the term, Customer can retrieve Customer Personal Data through the API and delete End Users at any time. Deleting an End User removes its connection records immediately and its stored request data through a background deletion that retries until it completes, normally within 24 hours and never later than the 15-day expiry that applies to all stored request data. Stored request data otherwise expires under the retention schedule in Annex 1.

When Customer's account closes, we delete the remaining Customer Personal Data within 30 days. Residual copies in our database provider's point-in-time recovery expire within a further 30 days and are not restored for any other purpose. Because we keep request data for 30 days or less, Customer should retrieve any data it needs before closing its account. We may keep Customer Personal Data where the law requires it, and we will protect any data kept that way under this DPA and process it only for that legal purpose.

15. US state privacy laws

Where the CCPA or a similar US state law applies, we act as Customer's service provider or contractor. We will not sell or share Customer Personal Data; will not retain, use or disclose it for any purpose other than the business purposes in the Terms, including any commercial purpose outside the direct business relationship with Customer; will not combine it with personal information we receive from others except as those laws permit; and will comply with those laws and provide the same level of privacy protection they require. We will notify Customer if we can no longer meet these obligations, and Customer may then take reasonable steps to stop and remediate unauthorized processing.

16. General

This DPA lasts as long as we process Customer Personal Data. Each party's liability under this DPA is subject to the limitations in the Terms, except where Data Protection Laws or the SCCs do not allow those limitations. The governing law and venue in the Terms apply to this DPA, except where the SCCs or UK Addendum require otherwise. We may update this DPA under the change process in the Terms, but no update will reduce the protection of Customer Personal Data during a paid billing period without Customer's agreement, unless the law requires the change.

Annex 1: Details of processing

Annex 2: Technical and organizational measures

Encryption

• All public endpoints require HTTPS. The Web Connector endpoint accepts TLS 1.2 or newer, and the website sends HTTP Strict Transport Security.
• Data at rest in our databases and object storage is encrypted by our infrastructure provider.
• Webhook signing secrets are additionally encrypted with AES-256-GCM. A Web Connector password is held encrypted only during setup, so the End User can view it again, and is deleted when setup completes or expires.

Credentials and authentication

• API secret keys, Web Connector passwords and setup-link secrets are high-entropy random values, stored only as HMAC-SHA-256 hashes with a server-side secret and compared in constant time. Secret keys are shown once and cannot be retrieved later.
• Dashboard accounts require a verified email address and a password of at least 12 characters, stored with a salted, memory-hard hash. Sign-in, sign-up and email-link requests are rate limited per IP address and per endpoint. Sessions are checked against the database on every request, expire after 7 days and are revoked on password reset.
• Dashboard cookies are HttpOnly, Secure, SameSite=Lax and limited to the dashboard path. Authentication requests and setup-flow forms are checked for origin to prevent cross-site request forgery.

Isolation and access control

• The project is derived only from the authenticated API key, every database query on customer tables is filtered by project, and requests for another project's resources return "not found".
• Each connection has its own isolated queue and storage, and every internal call verifies the expected project and connection. Stored objects are namespaced by project and connection and are never exposed by URL. Test and production projects use separate keys.
• Dashboard roles (owner, admin and member) limit who can manage keys, billing, webhooks and team members, and every server function re-checks the caller's membership.
• Production systems are accessible only to NMajor Studios personnel who need access. Our internal support view cannot display secret keys, setup links, Web Connector passwords, End User email addresses or request bodies, and every lookup in it is written to an audit log.

Data minimization and retention

• Our Web Connector configuration tells QuickBooks that personal data is not needed, so QuickBooks withholds Social Security numbers and full card numbers.
• Customers can turn off payload capture per project to keep bodies only until 24 hours after completion. The dashboard masks tax IDs, card, bank account and similar fields when displaying bodies.
• Automated jobs delete data on the retention schedule in Annex 1, backed by storage lifecycle rules.

Logging and monitoring

• Service logs record request IDs, operations, status and timings. They never contain authorization headers, API keys, Web Connector passwords, setup secrets, cookies or accounting bodies.
• Scheduled jobs report to independent monitoring, which alerts when a job fails or stops running. A public status page checks each component every five minutes.

Application and network security

• Content Security Policies on the website, documentation, dashboard and setup flow allow only approved script sources and permit inline code only by exact hash or per-request nonce.
• Rate limits on the API, failed authentication attempts, sign-in and website forms.
• Webhook deliveries are signed (Standard Webhooks, HMAC-SHA-256), refuse redirects, and are blocked from private and internal network addresses.
• The API never accepts cookies or browser credentials. Cross-origin browser requests are allowed only from our own documentation playground.

Resilience and change management

• Every request state change is written durably before it is acknowledged, so a restart resumes work instead of losing it.
• Our database provider keeps point-in-time recovery for 30 days.
• Changes pass automated type checks, tests and builds, and platform changes deploy to a separate staging environment before production.

Incident response and vendors

• We investigate suspected incidents, contain them and notify affected customers under section 9.
• We publish a vulnerability disclosure policy on our security page.
• We use a small number of subprocessors, listed publicly, and give each only the data its task requires.

Annex 3: Subprocessors

The current list of subprocessors, with their purposes and locations, is on our subprocessor page.