Data processing addendum

'You' means the firm using Fred to manage your fire-protection work - the controller of your customers' personal data. 'We' and 'us' mean Makappen Ltd, registered in England and Wales (company no. 11985285), registered office 33 Boston Road South, Holbeach, Spalding, Lincolnshire, England, PE12 7LR - the processor of that data. The two hats, set out plainly:

• For your customers' data that you put into Fred - site contacts, addresses, access notes, service history, certificates, photos - you are the controller and we are the processor. This addendum governs that processing.
• For your own account data - your firm's details, your team's names and logins - we are the controller. Our Privacy notice covers that.

This addendum forms part of the agreement between us, accepted with the Terms of use when your workspace is created. If it conflicts with the Terms of use on data protection, this addendum wins.

We'll process your customers' personal data only to provide Fred to you, and only on your documented instructions - which include your team's use of Fred's features. If the law ever requires us to process it some other way, we'll tell you first, unless the law forbids that.

If we ever think an instruction from you would break data protection law, we'll tell you rather than just carrying it out.

Everyone authorised to work with your data is bound by confidentiality and only sees what they need to do their job.

We keep appropriate technical and organisational measures in place, set out in Annex C. We may update them as Fred develops, but we won't lower the overall level of protection.

• You give us general authorisation to use the sub-processors listed in Annex B to help run Fred - that means you approve the list as a whole, rather than each provider one by one.
• We'll put obligations on each sub-processor no weaker than the ones in this addendum.
• We'll tell you before we add or replace a sub-processor, so you can object. If you reasonably object on data-protection grounds and there's no workable solution, you can end the affected part of the service.

Moving a paper register into Fred is the riskiest part of joining, so we offer to rehearse it first. If you ask us to, we load your real records into a separate rehearsal workspace, check what landed against your own paperwork, and only then do it for real. Nothing about your live workspace changes while a rehearsal runs, and you can join without one.

A rehearsal only happens if you ask for it in writing, and these terms apply while it runs:

• You stay the controller and we stay the processor, exactly as everywhere else in this addendum. Your written go-ahead is your instruction under clause 1.
• The rehearsal workspace is separate from the live service - its own database, reachable only by you and by the named person from us doing the work.
• Nothing can be sent from it. Email, text messages, card payments and Direct Debit are switched off in a rehearsal workspace, so nobody's customer is ever contacted from a test. The software enforces that.
• It holds your records for the rehearsal and no other purpose. We don't use them to improve Fred, and no AI feature runs over them unless you ask us to test that too.
• We delete it when the rehearsal ends, or within 30 days of your live workspace opening, whichever comes first - and we confirm in writing once it's gone. You can tell us to delete it sooner at any time, and we'll do it that working day.
• It runs in the United Kingdom, on the same providers and protections as the live service (Annex B).

Prefer to rehearse with made-up data? Say so and we will. It finds fewer problems, and the choice is yours.

If one of your customers asks to see, correct, delete or move their data, we'll help you respond - through Fred's features where we can, and otherwise on reasonable request. We won't respond to your customers directly unless you tell us to or the law requires it.

We'll give you reasonable help with your security duties, with reporting a personal-data breach to the ICO and, where the law requires it, to the people affected, with any data-protection impact assessment (the formal risk review the law sometimes asks a controller to run), and with consulting the ICO beforehand where that review shows a high risk you can't reduce. What we can give reflects how Fred is built and the information we hold.

If we become aware of a personal-data breach affecting your data, we'll tell you without undue delay and give you the information you reasonably need to meet your own 72-hour reporting duty to the ICO.

When our agreement ends, you choose: we'll return your customers' data to you in a usable form, or delete it, within 30 days of your instruction - keeping only what the law requires us to keep, and only for as long as it requires. We'll confirm once it's done.

We'll give you the information you reasonably need to show this addendum is being met, and allow audits - including inspections - on reasonable notice, run so they don't disrupt the service or expose other firms' data.

Some sub-processors process data outside the UK. Where they do, we rely on a transfer mechanism UK data protection law recognises; Annex B records which, per sub-processor.

Data protection law lets a person whose data was mishandled claim compensation, and they can bring that claim against either of us. As between the two of us, each side carries the cost of its own failure: if we have to pay because you broke your duties as controller or told us to do something unlawful, you'll cover that share; if you have to pay because we broke our duties as processor, we'll cover ours, our side up to the limit in the Terms of use. This decides who bears the cost between us; it doesn't reduce anyone's right to claim in the first place.

This addendum is governed by the law of England and Wales.

We'll tell you before this list changes (clause 4).

• Every connection runs over HTTPS, with strict transport security so browsers refuse an unencrypted link, and security headers set on every response.
• Each firm's data is isolated by row-level security enforced in the database itself: a query outside your firm's scope returns nothing, by construction.
• Role-based access inside a firm: sensitive fields, such as an absence type where you record one, are held only as a fixed category chosen from a list - never free text - shown only to the roles you allow, never on the everyday scheduling screens, and any change to them is captured in the activity trail below.
• Sign-in uses passwords stored as scrypt hashes, with optional passkeys (WebAuthn). Sessions are random tokens stored only as hashes, expiring after 30 days, and sign-in attempts are rate-limited.
• Card and bank details never reach Fred's servers; payments run through the provider's own hosted flow.
• Connection tokens Fred stores - your sending mailbox, your payment account - are encrypted at rest with AES-256-GCM.
• The database and file storage are encrypted at rest by the hosting provider, in London.
• Photos and floor plans live in a private storage bucket, readable only through short-lived signed links.
• Payment webhooks are verified by cryptographic signature, and internal service credentials are compared in constant time.
• An append-only activity trail records changes - who, what, when. Corrections are added as new records; originals stay.
• The statutory references and service intervals that feed certificates are covered by automated tests, so compliance records stay correct as the product changes.