Privacy Notice

1. About this notice

1.1 This notice explains how CERTSYNC LIMITED uses Personal Data about people who visit our website, create or use a CertSync account, use the CertSync apps, contact us, or whose details appear on a certificate prepared with CertSync.

1.2 We give this information under Articles 13 and 14 of the UK General Data Protection Regulation (the UK GDPR) and the Data Protection Act 2018.

1.3 In this notice:

• 1.3.1 "CertSync", "we" and "us" mean CERTSYNC LIMITED, trading as CertSync;
• 1.3.2 "Service" means the CertSync platform, website and mobile apps;
• 1.3.3 "Customer" means the person or business that holds a CertSync account and uses the Service to prepare, sign, store and deliver certificates;
• 1.3.4 "Personal Data" has the meaning in Article 4(1) UK GDPR;
• 1.3.5 "Sub-processor" means a provider we engage to process Personal Data for us or for a Customer (Article 28(2) UK GDPR);
• 1.3.6 "Authorised User" means a person a Customer allows to use its account, such as a member of its team; and
• 1.3.7 "Read-Only Grace Period" means the 90-day period that starts the day after a cancelled subscription's last billing cycle ends, during which the Customer can still view and export its data and can reactivate.

1.4 For data a Customer enters about other people, such as the homeowner named on a certificate, the Customer is the controller and we act as its processor under our Data Processing Agreement (see clause 7 of this notice). The Customer's own privacy notice explains how it uses that data.

2. Identity of controller

2.1 The controller of the Personal Data described in this notice, except where clause 7 says we act as a processor, is:

2.2 We are registered with the Information Commission (the ICO) under number ZC166774, which you can check at ico.org.uk.

2.3 Questions about this notice, and requests to use your rights under clause 11, go to:

2.4 We have not appointed a Data Protection Officer because Article 37 UK GDPR does not require one: we are not a public body, and our core activities do not involve large-scale monitoring of people or large-scale processing of special category or criminal-offence data.

3. Personal Data we process

3.1 We group the Personal Data we process as follows.

3.2 Account Data. About Customers and Authorised Users: name, email address, password (stored only as a salted hash), phone number, trading or company name, company address and logo, competent person scheme name and membership number, Companies House and VAT numbers, subscription plan, marketing preferences, and sign-in history and security signals (last sign-in, failed attempts, account lock). When you create an account we keep a record that you accepted our Terms of Service and confirmed you had read this Privacy Notice, noting the date of each version, the time, a shortened form of your IP address and your browser type, so we can show what you agreed to and when.

3.3 Certificate Content. What a Customer enters when preparing a certificate: the name and address of the person the certificate is for, the installation address, test readings, observations, photographs and signatures. We process it as the Customer's processor (clause 7 of this notice).

3.4 Cross-Certificate Memory and Customer Notes. Customer, site and contact details an Authorised User has entered before, which the Service saves so that the Customer's users can pre-fill later certificates, and any notes they record against a customer (for example access arrangements). This data is never shown to or used for any other Customer, and we process it as the Customer's processor (clause 7 of this notice). Please do not record health or other sensitive details in notes.

3.5 Payment Metadata. Your Stripe customer and subscription identifiers, plan and billing cycle. Stripe issues your invoices and keeps them, with the payment history, in our Stripe account; each invoice shows the billing name, email address, amount and date. We do not hold card numbers or copies of invoices in our own systems.

3.6 Audit and Security Data. Records of actions in the Service, security events (failed sign-ins, blocked addresses, multi-factor checks, password resets), IP addresses, browser and device details, and session identifiers.

3.7 Communications Data. Delivery records for the emails we send, sign-in code records, your correspondence with us (including complaints and rights requests), and, if you allow notifications, the push address your browser assigns or the device token the CertSync app receives (clause 16.8).

3.8 Cookie, Analytics and Attribution Data. Data collected through cookies and similar technologies on our website, including, if you consent, how you reached us (campaign tags, the referring website and the first page you saw), which is saved with your account if you sign up. The Cookie Policy lists each one.

4. Sources of Personal Data

4.1 From you. You give us Account Data when you create or update an account, change plan or set your preferences, and your own details when you add them to a certificate, for example as the signing electrician. We need Account Data to create your account and provide the Service; without it we cannot do so.

4.2 From a Customer, about other people. We receive details of homeowners, occupiers and clients when a Customer enters them into a certificate or saves them for later certificates.

4.3 Automatically. We collect IP addresses, device details, session records and Audit and Security Data when the Service is used, and cookie and analytics data only as the Cookie Policy describes.

4.4 From our providers. Stripe tells us about payment events (for example a paid or failed invoice), and Resend tells us whether our emails were delivered.

4.5 From Google, if you sign in with Google. Sign-in with Google is switched off at present. If we switch it on and you use it, Google, as the identity provider, will give us your name, email address, profile picture and Google account identifier, and the sign-in tokens needed to keep you signed in. Google handles your Google account under its own privacy policy as an independent controller.

5. Purposes of processing

5.1 To provide the Service: signing users in, running checks and calculations, producing and storing certificates, delivering them by email, and letting anyone with the QR code and postcode check that a certificate is genuine.

5.2 To bill Customers and keep financial records: charging subscriptions through Stripe and keeping the payment records tax law requires.

5.3 To keep the Service secure: detecting and stopping unauthorised access, fraud and abuse, recording software errors on the website and in the apps, and removing offline copies from devices whose access has ended (clause 16.7).

5.4 To meet legal obligations and keep records: complying with data protection, company and tax law, handling complaints and rights requests, and keeping the record of what each user accepted at sign-up (clause 3.2).

5.5 To pre-fill certificates: offering the Customer's users details they have entered before (Cross-Certificate Memory). We do this for the Customer, as its processor.

5.6 To send service emails and notifications: account and security alerts, billing messages, certificate-delivery confirmations, deletion warnings, and the website and app notifications you allow.

5.7 To send marketing emails, if you agree: news about CertSync and tips on getting set up. You can unsubscribe using the link in any such email or by writing to us (clause 2.3).

5.8 To measure use of the website and our advertising, if you agree: with Analytics consent we use Google Analytics 4, Vercel Web Analytics and Vercel Speed Insights to understand how the website is used and how fast it loads, and Sentry to record sessions on the signed-in dashboard (with all text and form entries masked) to find faults. With Marketing consent a Google Ads tag reports sign-ups that follow a Google advert. With either consent we record how you reached us and save it with your account if you sign up, so we can see which channels lead to sign-ups. Without consent, none of this happens.

5.9 To measure how accurate AI-assisted features are. When an Authorised User reviews an AI board scan, CertSync records, for each field the scan suggested, what the reviewer did with it: kept it, edited it, rejected it, or filled it in after the scan could not read it ("AI Correction Records").

• (a) The records hold no field values unless the reviewer chooses to share them: they say which field it was and what was done with it. Where the Service offers the option to "Share what the scan got wrong", it is unticked on every review and is not remembered for the next one. Where the reviewer ticks it on a review, the record for a field of that review whose answer is chosen from a fixed list also holds the option the scan suggested and the option the reviewer recorded. Those are technical values only, for example the number of ways, a device's kind, type, standard and rating, its RCD protection and RCD type, the main switch's type and rating, a cable size, the direction the ways are numbered in, and whether a way is spare. A circuit name or description, a board manufacturer, anything typed in free text, an address or a name is never kept, whether or not the box is ticked.
• (b) AI Correction Records never contain photographs, the content sent to or returned by the AI processor, or the certificate itself.
• (c) Each record is linked to the reviewing Authorised User and their team, so it is deleted when that person's account or the team's account is deleted, and it is included when that person exports their data.
• (d) CertSync uses these records only to measure and improve the accuracy of its AI-assisted features, through an internal accuracy report, which shows a field only when it has at least 20 corrections from at least 3 teams and no one team supplied more than 50 per cent of them. The report contains no names, no team or user identifiers and no field values, except the most frequent suggested-and-recorded option pairs for a field, each shown only when it comes from at least 3 corrections and at least 2 teams.

6. Lawful basis for each purpose

6.1 This table gives the lawful basis under Article 6(1) UK GDPR for each purpose in clause 5.

6.2 Where we rely on legitimate interests, we have weighed them against your interests and rights. You can ask us about that assessment at privacy@certsync.co.uk, and you can object (clause 11.1.6).

7. CertSync's role: Controller and Processor

7.1 We act in two capacities under the UK GDPR.

7.2 As controller (Article 4(7)) for:

• 7.2.1 Account Data;
• 7.2.2 Payment Metadata;
• 7.2.3 Audit and Security Data;
• 7.2.4 Communications Data; and
• 7.2.5 Cookie, Analytics and Attribution Data.

7.3 As processor (Article 4(8)), on the Customer's instructions, for:

• 7.3.1 Certificate Content and the certificate PDFs made from it;
• 7.3.2 Cross-Certificate Memory and Customer Notes;
• 7.3.3 records of certificate deliveries the Customer makes (recipient email address and delivery status);
• 7.3.4 records of QR-code verification of a certificate (the number and time of scans and postcode checks); and
• 7.3.5 the offline copy of this data held on users' devices (clause 16.5).

7.4 Our Data Processing Agreement at /dpa governs the data in clause 7.3. Customers accept it when they sign up and can download it at any time.

7.5 We do not use the data in clause 7.3 for our own purposes. We use it only to provide, secure and support the Service for the Customer.

7.6 AI Correction Records. CertSync is the controller of the AI Correction Records described at clause 5.9, which CertSync creates for its own purpose of measuring and improving the accuracy of its AI-assisted features. This includes any options a reviewer chose to share under clause 5.9. They are held separately from Certificate Content, which CertSync continues to process as processor under clause 7.3.

8. Recipients and Sub-processors

8.1 We share Personal Data with:

• 8.1.1 Sub-processors that help us run the Service. The Sub-processor list gives each one's role, the data it receives, where it processes it and the transfer safeguard. It is Schedule 1 to the Data Processing Agreement.
• 8.1.2 Companies that act for themselves (independent controllers): Stripe, for card details and payment history; Google, for Google Ads conversion measurement, with your consent; the push service run by your browser's maker (for example Google, Mozilla, Microsoft or Apple) when you allow browser notifications; Apple Push Notification service for app notifications on iPhones and iPads; Apple and Google as app stores; and Google, if you sign in with Google (clause 4.5).
• 8.1.3 The Customer's team, according to the roles the Customer sets.
• 8.1.4 Certificate recipients. A person a Customer sends a certificate to receives it in full as a PDF. Where a Customer turns on QR-code verification, anyone who scans the code and enters the property postcode can view and download a redacted copy, which leaves out names and contact details, signatures and photographs, and shows the issuing company.
• 8.1.5 Professional advisers (accountants, auditors, insurers and lawyers) under a duty of confidence.
• 8.1.6 Public authorities, such as the Information Commission, HM Revenue and Customs and the police, where the law requires it or for legal proceedings.
• 8.1.7 A buyer or successor of our business, with notice to Customers where the law requires.

8.2 Our main Sub-processors. MongoDB Atlas (database, London region); Vercel (hosting, and file storage for certificate PDFs and photographs); Upstash (sign-in sessions and rate limiting); Resend (email, including sign-in codes); Stripe (payments); error monitoring on the website and in the apps (Sentry, EU data region); product analytics on consent (Google Analytics 4, Google Ireland Limited; Vercel Web Analytics and Speed Insights); and app notifications (Firebase Cloud Messaging, Google). Where an Authorised User uses an AI-assisted feature (for example an AI board scan or AI observation suggestions, or another feature described at clause 8.5), the photographs, notes and certificate content they choose to submit are sent to an AI processor: Google Cloud EMEA Limited, which provides a large-language-model service (Google Cloud Vertex AI) that CertSync engages as a Sub-processor and lists, with its transfer mechanism, on the Sub-processor list. The model used is Google Gemini or Anthropic Claude, both used through Google Vertex AI. The AI processor returns suggestions only, and the Authorised User reviews every suggestion before anything is written to a certificate. Google’s terms for that service state that it does not use the submitted content to train or fine-tune its models without CertSync’s permission or instruction, and CertSync gives none. CertSync sends AI requests only to Google’s EU endpoint (the Vertex AI “eu” multi-region). Google states that processing on that endpoint stays in the EU for the models it lists; for the Claude model, CertSync is awaiting Google’s written confirmation that processing stays in the EU.

• 8.2.1 Help-centre feedback. If you mark a help-centre article as unhelpful, any comment you type is included in the resulting Sentry alert. Email addresses and phone numbers are removed from it automatically, but please do not type other personal details about yourself or your clients.
• 8.2.2 Sign-in locations. We work out a sign-in's rough location from its IP address using a copy of the MaxMind GeoLite2 database held in our own storage, so no IP address is sent to MaxMind.

8.3 New Sub-processors. We add any new Sub-processor to the list and update its date. Where a change is material we also email Customers, who may object as the Data Processing Agreement sets out.

8.4 Notes typed for AI observation suggestions. Where an Authorised User types notes for AI observation suggestions, those notes are sent to the AI processor with the request. Do not type names, addresses or other details of a person into that box. Before the notes are sent, CertSync removes text that looks like a UK postcode or an email address. This is a safeguard, not a guarantee: a name or a street address has no fixed shape that can be recognised reliably.

8.5 What AI-assisted features send and keep. Where CertSync offers an AI-assisted feature, the item the Authorised User selects or enters for a request is sent to the AI processor only when they start that request, together with the context the feature needs to make its suggestion (for example the team's own saved observation wording, used as examples).

• (a) Depending on the feature, that item may be: a photograph of a distribution board, meter, cut-out, equipment rating plate or instrument display; a photograph of a defect, with any short note or location label the Authorised User adds; notes typed for observation wording; a question about a published standard; or, for a certificate summary, the certificate's observations, test readings and condition sections, with the client's name, address and contact details, the names of the inspector and signatories, and the certificate number left out. A photograph may incidentally show a person or the inside of a property. Where a feature reads a photograph of a meter or cut-out, it does not record the meter serial number, the meter point administration number (MPAN) or the meter reading.
• (b) The AI request itself stores no photograph. The photographs taken for an AI board scan are saved with the certificate as its photographic evidence once the scan request has been sent, even when the scan fails, and are kept and deleted with that certificate, like any other certificate photograph. A photograph the Authorised User attaches to a certificate (for example a defect photograph attached to an observation) is held in the same way. Only what the Authorised User accepts from a suggestion is written to a certificate, and it is then held and deleted as part of that certificate. Apart from that, CertSync does not keep the content sent to the AI processor or the response once the request ends, with one exception: for 24 hours after a board scan is delivered, CertSync keeps a record that ties a free retry of the ways the scan could not read to that scan and its photographs. That record holds a one-way fingerprint (hash) of each photograph, from which the photograph cannot be rebuilt, the number of ways and way numbers the scan found, and the board details it read, which can include text read from the board's labels. It holds no photograph and is deleted automatically after 24 hours.
• (c) Where CertSync offers spoken entry of readings, speech is turned into text by the speech-recognition service of the user's own device or browser, under that provider's terms; CertSync does not receive or keep the audio and does not send it to the AI processor, and the text is shown for the Authorised User to confirm.
• (d) For each request CertSync keeps a usage record of the feature used, the outcome and the credit cost, which holds no part of the content sent or returned and is deleted with the account; where CertSync offers team spending limits, the team's account administrator can see how many credits each Authorised User has used.
• (e) If one AI model does not answer, the same request may be sent to the second AI model named in clause 8.2, only through the same AI processor. To answer faster, the same request may be sent more than once to the same AI processor.
• (f) No AI-assisted feature makes a decision about a person: every suggested value, wording or classification code is accepted, changed or rejected by the Authorised User, and clause 11.1.7 applies.

8.6 Improving the AI-assisted features. CertSync does not use the content submitted to AI-assisted features to train, fine-tune or otherwise improve any AI model, and does not keep that content for that purpose; the AI Correction Records described at clause 5.9 hold none of it. If CertSync offers a team the option of allowing the photographs it submits, and the corrections it makes to the suggestions, to be kept to improve the AI-assisted features, the option will be off unless the team's account administrator turns it on. Before anything is kept under it, this notice will set out what is kept, how personal details are removed from it first, the lawful basis relied on and how long it is kept, and turning the option off will stop anything further being kept.

9. International transfers

9.1 Our main database is in the United Kingdom (MongoDB Atlas, London). Some Sub-processors process data elsewhere. Each transfer out of the UK meets Chapter V of the UK GDPR, as amended by the Data (Use and Access) Act 2025, through one of these:

• 9.1.1 UK adequacy regulations, for example for the European Economic Area;
• 9.1.2 the UK-US Data Bridge, for a US company certified to the UK extension of the EU-US Data Privacy Framework; or
• 9.1.3 the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, with a transfer risk assessment and extra safeguards where needed.

9.2 The Sub-processor list shows which applies to each provider. You can ask us for a copy of the safeguard (clause 2.3).

10. How long we keep your Personal Data

10.1 The account's data. We keep an account's data while its subscription is active and through the Read-Only Grace Period that follows cancellation. Unless the Customer reactivates, we then delete it, as clause 3 of the Data Retention Policy sets out step by step. Only the records in clause 10.3 are kept longer, for the period stated there.

10.2 Day 91. On the day after the Read-Only Grace Period ends (day 91) we delete the account's Personal Data, including Certificate Content, Cross-Certificate Memory and Customer Notes, and our Sub-processors delete what they hold for it. The exports the Customer downloaded (the JSON data export, the certificate PDFs with their photographs, and the CSV summary) are then the Customer's own record.

10.3 Records kept longer. Only these are kept after day 91:

• 10.3.1 Payment records. We keep the invoices in clause 3.5 for 6 years after the end of the accounting period in which the payment was made, and longer only while an HMRC enquiry is open, as the Finance Act 1998 (Schedule 18, paragraph 21) requires. Closing your account does not delete them. We then delete or anonymise the personal elements (name, email and billing contact).
• 10.3.2 Anonymised security logs. When a user is deleted we replace the user identifier, email address, IP address and device details in their audit-log entries with a fixed redacted marker. We keep the anonymised log for six years, so we can bring or defend legal claims within the limitation period (Limitation Act 1980). It no longer identifies anyone.
• 10.3.3 Complaint records. We keep a record of each privacy complaint, and how we handled it, for six years after we close it, so we can show how we met our complaints duty and can bring or defend legal claims (Limitation Act 1980). It is held in our privacy mailbox, not in your account.
• 10.3.4 AI credit purchase records. Where a Customer buys AI credits, we keep a record of each purchase (the payment reference, the number of credits and the date) as a financial record for at least 6 years after the end of the accounting period in which the purchase was made (Finance Act 1998, Schedule 18, paragraph 21). The record carries no user identifier, account identifier or email address, but the payment reference can be matched to the payment held by Stripe, so we treat it as Personal Data. The credit ledger is the Customer's own financial record of how its credits were granted and spent. Each spend keeps a reference to the Authorised User who made it (an internal identifier, not a name or email address), and that reference stays on the ledger after the Authorised User leaves the Customer or their own account is erased. The ledger is deleted in full with the Customer's account at day 91, or earlier if the Customer's account is erased sooner.

10.4 Stripe. Stripe holds card details and card-transaction history as a controller under its own privacy policy and legal duties. At day 91 we remove the Stripe customer identifier from your account and ask Stripe to delete the customer (the invoices in clause 10.3.1 stay in our Stripe account), but Stripe may keep records it must keep by law.

10.5 Backups. Deleted data stays in our encrypted backups until they expire, no later than 190 days after deletion. It is not used in that time, and if we ever restore a backup we delete it again. The Data Retention Policy gives the schedule.

10.6 The Customer's own obligations. A Customer may need to keep certificate records for longer, for example under its competent person scheme, HMRC rules or the Limitation Act 1980. Those are the Customer's obligations as controller, so Customers should keep their exports for as long as they need them.

10.7 Leaving a team. If you leave or are removed from a team, your account is deleted 90 days later; certificates you created for that team stay with the team.

11. Your rights (Articles 15–22D UK GDPR)

11.1 Subject to the conditions in the UK GDPR, you have these rights over Personal Data we hold about you as controller:

• 11.1.1 Access (Article 15): to know whether we process your data and to get a copy.
• 11.1.2 Rectification (Article 16): to have inaccurate data corrected and incomplete data completed.
• 11.1.3 Erasure (Article 17): to have your data deleted where Article 17(1) applies (see clause 11.4).
• 11.1.4 Restriction (Article 18): to limit how we use your data in the cases in Article 18(1).
• 11.1.5 Portability (Article 20): to receive the data you gave us in a machine-readable format, or have it sent to another controller where feasible. The JSON data export (clause 10.2) provides this.
• 11.1.6 Objection (Article 21): to object to processing based on legitimate interests, and to direct marketing at any time.
• 11.1.7 Automated decisions (Articles 22A to 22D): we do not take significant decisions about anyone based solely on automated processing, including profiling. AI-assisted features make suggestions only, and a person reviews every suggestion before it is used.
• 11.1.8 Withdrawing consent (Article 7(3)): where we rely on consent (purposes 5.7 and 5.8), you can withdraw it at any time. This does not affect processing before you withdrew.

11.2 Making a request. Contact us at clause 2.3. We will reply within one month. That month starts when we receive the request or, if later, when we have confirmed who you are. If we ask you to clarify what you are asking for, the time until you reply does not count. We may extend by two further months for complex or numerous requests, and will tell you why within the first month. We search for your data as far as is reasonable and proportionate.

11.3 Checking identity. We may ask for information to confirm who you are, so that we do not disclose data to the wrong person.

11.4 Erasure during the grace period. A Customer in the Read-Only Grace Period can ask us to delete its data straight away rather than at day 91, and we will confirm when it is done.

11.5 Limits on erasure. The right to erasure does not apply where we must keep data by law or to bring or defend legal claims (Article 17(3)(b) and (e)), which covers the records in clause 10.3 for their stated periods.

11.6 If your details are on a certificate. If an electrician or contractor recorded your details on a certificate, in Cross-Certificate Memory or in a note, they are the controller, so please send your request to them. If you send it to us, we will pass it on and help them respond, as the Data Processing Agreement requires.

12. Your right to complain

12.1 If you think we have handled your Personal Data in a way that breaks data protection law, you have the right to complain to CertSync. You can use the form at certsync.co.uk/privacy/complaint, or write to privacy@certsync.co.uk or to the postal address at clause 2.3.

12.2 We will acknowledge your complaint within 30 days of receiving it.

12.3 We will look into it without undue delay, keep you informed of progress and tell you the outcome.

12.4 If your complaint is about how an electrician or contractor used your details on a certificate, they are responsible for that use. We will pass your complaint to them and help them respond.

12.5 We use the details you give us only to handle your complaint and keep a record of how we handled it. We keep that record for six years after we close the complaint.

12.6 You can also complain to the Information Commission (the ICO), the UK data protection regulator, at any time: ico.org.uk/make-a-complaint.

13. Security

13.1 We protect Personal Data with measures suited to the risk, including:

• 13.1.1 encryption at rest for the whole database (MongoDB Atlas), and AES-256-GCM encryption of multi-factor backup codes and of backups;
• 13.1.2 encryption in transit using TLS 1.2 or higher;
• 13.1.3 passwords stored only as salted bcrypt hashes;
• 13.1.4 Role-based access control with four roles (Installer, Supervisor, Office, Admin), and each Customer's data kept separate from every other Customer's;
• 13.1.5 multi-factor authentication, on by default for every account, using emailed one-time codes and backup codes; a device you choose to trust skips the code for 30 days;
• 13.1.6 logging of security events, with personal identifiers anonymised when a user is deleted;
• 13.1.7 our main database held in the UK; and
• 13.1.8 secure development, monitoring of software vulnerabilities, and an incident response process.

13.2 No system is completely secure. If a personal data breach occurs we will tell the ICO within 72 hours where Article 33 requires, and tell the people affected without undue delay where Article 34 requires.

13.3 Emails. A certificate-delivery email shows only the start of the installation postcode (for example “ending SW1A”); the full details are in the attached certificate. A security-alert email shows only the first part of the IP address (for example “192.x.x.x”) and a general location, unless you have asked for full details.

14. Cookies

14.1 Our website uses strictly necessary cookies, and analytics and marketing cookies only with your consent, which you can withdraw at any time. The Cookie Policy lists each cookie, what it does and how long it lasts.

15. Changes to this notice

15.1 The "Last updated" date at the top and bottom of this notice is the date of the current version.

15.2 If we make a material change, we will email Customers before it takes effect.

15.3 Earlier versions are available from privacy@certsync.co.uk.

16. Offline working and the mobile apps

16.1 This clause covers the CertSync apps for iOS and Android (the “Mobile Apps”) and offline working on the website. The rest of this notice applies to them in the same way.

16.2 No purchases in the app. The Mobile Apps sell nothing. Accounts and billing are managed at certsync.co.uk, so the Mobile Apps collect no payment details.

16.3 Signing in and app lock. You sign in with your email address, password and an emailed code, as on the website. If you turn on app lock, your device checks your face or fingerprint before releasing your saved sign-in from its secure storage. We never receive, store or process a fingerprint, face scan or other biometric data.

16.4 Camera and photos. The Mobile Apps use the camera or photo library only when you choose to take or attach a photo, and your device asks your permission first. A photo you attach becomes part of the Certificate Content. No other photo is read or uploaded.

16.5 Offline copy. So you can work without signal, the certificates, customers, sites and related records you can see are kept on your device in encrypted form. Changes made offline are sent to us when the device is back online.

16.6 Access check. Your device also keeps a small access record: your user and team identifiers and a signature we issue. It stays on the device after you sign out, so that we can tell the device to delete its offline copy if your access ends. It gives no access to any data. It is deleted when the offline copy is removed under clause 16.7 because your access has ended, or when someone else signs in on that device.

16.7 Removing the offline copy. The offline copy is deleted when you sign out with nothing left to sync, or when you choose to clear offline data. If changes are still waiting to sync when you sign out, they stay on the device, encrypted, until they are sent. The copy, including unsynced changes, is also deleted the next time the device connects to us after your access has ended because your account was deleted or closed, you left or were removed from your team, or the team was deleted. We do this in our legitimate interest in keeping data secure (Article 6(1)(f)). A device that never connects again keeps its encrypted copy until the app's data is removed from it, for example by uninstalling the app or clearing the site's data in the browser.

16.8 Notifications. If you allow notifications, the Mobile App receives a device token from Firebase Cloud Messaging (Google), which reaches iPhones and iPads through Apple Push Notification service. We store the token with a random identifier for the app installation, the platform and the app version, and use them only to deliver your notifications and manage your app sign-in. A Mobile App notification is generic: it names no certificate, customer, site or person.

16.9 Error reports. The Mobile Apps send reports of software errors to Sentry (EU data region) so we can fix faults. The reports do not include your name, email address, account identifier or IP address, and the Mobile Apps never record your screen.

16.10 App updates. The Mobile Apps are updated through the App Store and Google Play only. If we start updating them another way, we will update this notice first.

16.11 App stores. Apple and Google process data about downloads, updates and your store account as independent controllers under their own privacy policies.

16.12 Deleting your account in the app. Go to Settings, then Account, then Delete Account. This works as it does on the website, and clause 10 applies.