Privacy Notice

01 Who we are and how to contact us Controller & processor

This notice is published by WESTPORT CYBER LIMITED, a private company limited by shares registered in Northern Ireland under company number NI741244, whose registered office is at 125 Jordanstown Road, Newtownabbey, Northern Ireland, BT37 0NT. The company trades under the name Lagan Cyber. Where this notice says “we”, “us” or “our”, it means WESTPORT CYBER LIMITED.

The company was incorporated on 7 June 2026. At the effective date of this notice it is pre-launch: it has no customers, no paying subscribers and no live production platform available to the public. This notice is written to describe how we will handle personal data, and how we handle the small amount of personal data we hold today, which consists almost entirely of email correspondence from people who have contacted us.

1.1 Contact for data protection matters

All data protection correspondence, including requests to exercise your rights, should be sent to hello@lagancyber.co.uk, or by post to the registered office above marked for the attention of the Data Protection Lead.

We have not appointed a statutory Data Protection Officer under Article 37 UK GDPR. We have assessed that we are not currently required to appoint one: we are not a public authority, our core activities do not consist of regular and systematic monitoring of data subjects on a large scale, and they do not consist of large-scale processing of special category or criminal offence data. We keep this assessment under review and will appoint a DPO and publish their contact details here if the position changes. Data protection responsibility currently sits with the company’s directors.

1.2 Registration with the Information Commissioner

Our application to pay the data protection fee and appear on the Information Commissioner’s register of fee payers is in progress. We will publish the registration number in this section and on our status page once it is issued. We do not claim to be registered before that has happened.

1.3 Representatives

We are established in the United Kingdom and have no establishment in the European Union. Where we offer services to individuals in the EEA in a way that brings us within the territorial scope of the EU GDPR, we will appoint an Article 27 representative and publish those details here. We have not done so yet because we have no customers.

02 Scope of this notice Controller & processor

This notice covers:

• the website at lagancyber.co.uk and any subdomain of it;
• email and other correspondence with us;
• the Lagan Cyber platform, when it becomes available, including any web application, application programming interface and any future mobile application;
• our administration of customer, supplier and prospective-employee relationships.

It does not cover third-party websites that we link to. Where we link to an external site — for example the Information Commissioner’s website — that organisation is responsible for its own processing and you should read its own notice.

It also does not describe, and cannot describe, what our customers do with personal data in their own organisations. Where a customer uses the platform to assess their own security posture, the customer decides what data goes in and why. If you are an employee of one of our customers and you want to know how your employer handles your data, ask your employer.

2.1 Applicable law

We process personal data in accordance with the UK General Data Protection Regulation as it forms part of the law of England and Wales, Scotland and Northern Ireland by virtue of section 3 of the European Union (Withdrawal) Act 2018 (“UK GDPR”), the Data Protection Act 2018 (“DPA 2018”), and the Privacy and Electronic Communications (EC Directive) Regulations 2003 as amended (“PECR”). Where the EU GDPR applies to a particular processing operation — for example where we serve a customer established in Ireland — we will comply with it in respect of that operation.

03 Controller and processor: the two roles Controller & processor

Under Article 4 UK GDPR, a controller determines the purposes and means of processing personal data. A processor processes personal data on behalf of a controller, on that controller’s documented instructions, and does not decide for itself what the data is for.

3.1 When we are a controller

We act as a controller in respect of:

• people who visit this website (section 5);
• people who email us or apply for early access (section 6);
• the individuals who hold accounts on our platform, in respect of the account itself — their name, work email address, authentication data, and their activity within our service (section 7);
• customer contacts, billing contacts and the administration of the customer relationship (section 8);
• our own suppliers, contractors and professional advisers (section 9);
• people who apply to work with us (section 10);
• our own security logging, fraud prevention and legal-compliance activities.

3.2 When we are a processor

We act as a processor in respect of the content a customer puts into, or connects to, the platform. That includes:

• cloud-configuration and posture data read from the customer’s Microsoft 365, Entra ID, Azure or Google Workspace tenant, including account identifiers and role assignments belonging to that customer’s staff;
• evidence records generated from that data, and the findings within them;
• security policy documents the customer uploads, and the acknowledgement records showing which of their staff read which version;
• supplier questionnaire content, including the names and contact details of individuals at the customer’s suppliers;
• security-awareness training completion records and phishing-simulation results relating to the customer’s staff.

In each of those cases the customer is the controller. They decide which tenants to connect, which staff to enrol, which suppliers to question and how long to keep the results. We act on their instructions as set out in our contract with them and in section 17.

3.3 Where the line falls

One dataset can involve both roles. If an administrator at a customer logs into our platform, the record of their login is controller data for us — we decide to keep security logs and why. The scan they run against their tenant produces processor data — they decided to run it, against which tenant, and what to do with the result.

We do not use processor data for our own purposes. We do not mine customer evidence records to build benchmarks, industry averages, threat intelligence, marketing content or training data for machine-learning models. If we ever wanted to do something of that kind we would have to become a controller for that purpose, which would require a separate lawful basis, a separate notice and, in practice, the customer’s agreement. We have no such plans.

04 Summary of processing activities Controller & processor

The table below is an index. The detailed inventories are in the sections that follow.

05 Website visitors Controller

This website is deliberately simple. It is static HTML with one stylesheet and one small JavaScript file. It sets no analytics cookies, no advertising cookies and no cookies of our own at all. It does not use tag managers, pixels, session-recording tools, heat mapping, A/B testing tools, chat widgets or embedded social media components.

Two things nonetheless involve personal data or data that can in some circumstances identify you: the request logs kept by our hosting and content-delivery provider, and the request your browser makes to Google Fonts to fetch the two typefaces this site uses.

5.1 A note on Google Fonts

We load the Inter and IBM Plex Mono typefaces from Google’s font service. This means your browser makes a request to fonts.googleapis.com and fonts.gstatic.com, and Google will see your IP address and user-agent as a result. Google states that the font service does not set cookies and that requests are logged separately from other Google services. We do not receive any data from Google about you and we do not have an account relationship that would let us identify you from those requests.

We consider this a proportionate use of legitimate interests, but we recognise it is a transfer of your IP address to a third party that you did not separately agree to. Self-hosting the fonts would remove it, and this is on our list of changes. If you would prefer not to make that request, a content blocker or a browser configured to block third-party requests will prevent it; the site is designed to remain fully legible in your system typefaces if the webfonts do not load.

5.2 What we do not do

We do not profile visitors, build audiences, run remarketing, share data with advertising networks, or attempt to identify individual visitors from server logs. We do not currently measure traffic at all. If we introduce any form of analytics, section 28 and the cookie policy will be updated before it is deployed, and anything requiring consent will ask for it.

06 Enquirers and early-access applicants Controller

There are no forms on this website. The only route in is email. When you write to hello@lagancyber.co.uk we receive whatever you choose to send: your email address, your name and signature block if you use one, your employer, and the content of your message.

6.1 What we will not do with your email address

We will not add you to a mailing list, send you a newsletter, enrol you in a drip sequence, or pass your details to anyone for marketing. We do not operate a customer relationship management system that scrapes your email signature into a prospect database. We answer your message and, unless you become a customer, that is the end of it.

If you have written to us and want your correspondence deleted, ask, and we will delete it — subject only to anything we are required to retain for a legal reason, which for ordinary enquiry correspondence is nothing.

07 Account holders and platform users Controller

This section describes the account itself. It is controller data because we decide what an account record needs to contain and how we secure it. It is separate from the content inside the account, which is processor data and is covered by sections 14 to 17.

7.1 Visibility to your employer

If your account exists because your employer subscribes to our service, your employer’s administrators can see your account details, your role, and your activity within the platform. That is normal for a business tool and is part of what makes an audit trail useful, but you should know it. If you do not want your employer to see something, do not put it into our platform.

08 Customer contacts, billing and administration Controller

We hold the business contact details needed to run a commercial relationship: who signed the contract, who receives invoices, who is the technical contact, who is the named security contact for incident notification.

At the effective date of this notice we take no payments and have no payment provider. We will name the provider in section 18 before the first payment is taken.

09 Suppliers, contractors and advisers Controller

We hold contact and contractual data for the organisations and individuals we buy from — hosting, email, professional services, accountancy and legal advice. Where our supplier is a sole trader or an individual contractor, their contract data is personal data and we process it under Article 6(1)(b). Where our supplier is a company, we process the business contact details of its staff under Article 6(1)(f), our interest being the administration of a supply relationship we have entered into.

Supplier records, including invoices received, are retained for six years from the end of the relevant accounting period for the same statutory reason given in section 8.

Where a contractor has access to systems that contain personal data, we carry out proportionate due diligence before granting it, put a written contract in place with confidentiality and security obligations, and grant the least access that lets them do the work.

10 Applicants and recruitment Controller

We are not currently recruiting. If and when we do, this section will govern it.

We do not use automated screening tools, CV-ranking algorithms or video-interview scoring systems, and we have no plans to. Every application is read by a person.

11 Lawful bases in full Controller

Article 6(1) UK GDPR sets out six lawful bases. We rely on four of them. We do not rely on Article 6(1)(d) vital interests or Article 6(1)(e) public task.

12 Our legitimate interests Controller

Where we rely on Article 6(1)(f) we have carried out a balancing exercise. Summaries follow; the full assessments are available on request to hello@lagancyber.co.uk.

12.1 Website operation and security

Interest: publishing a website and keeping it available and free from abuse. Necessity: a web server cannot serve a page without processing the requesting IP address; denial-of-service mitigation cannot work without inspecting traffic. Balance: the data is limited to what the protocol requires, retained briefly by our provider, never used to identify or profile individuals, and never combined with other sources. We consider the impact minimal and within the reasonable expectations of anyone using the web.

12.2 Answering correspondence

Interest: replying to people who write to us. Necessity: we cannot answer an email without processing the sender’s address and message. Balance: you initiated the contact and expect a reply; we do not repurpose the data for marketing; we delete threads after 24 months. The impact is minimal and the alternative — not replying — serves nobody.

12.3 Business contact administration

Interest: managing relationships with customers, suppliers and advisers. Necessity: a business relationship requires named contacts. Balance: the data is work contact data provided in a professional capacity, held for a defined period, and used only for the relationship it relates to.

12.4 Security logging, fraud and abuse prevention

Interest: protecting a platform that holds sensitive security-posture information about other organisations. Necessity: Article 32 requires appropriate technical measures; an audit trail is one of the most basic. Balance: the logging is proportionate to the sensitivity of what is being protected, is retained for a defined 13 months, is visible to the customer organisation whose data is being protected, and is not used for performance monitoring of individuals. Recital 49 recognises network and information security as a legitimate interest.

12.5 Your right to object

You can object to any processing based on legitimate interests at any time under Article 21(1), on grounds relating to your particular situation. We will stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or the processing is for the establishment, exercise or defence of legal claims. If your objection concerns direct marketing, the right is absolute and we will stop without any balancing exercise.

13 Special category and criminal offence data Controller & processor

As controller, we do not seek, and have no need for, any special category data under Article 9 — data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric data, health data, or data concerning sex life or sexual orientation. We do not seek criminal offence data under Article 10.

Our platform is not designed to hold special category data and our contracts will instruct customers not to put it there. If special category data reaches us anyway — for example because a customer uploads a policy document containing a health-related case study, or a supplier questionnaire response includes it — we treat it as an incident to be corrected rather than a dataset to be exploited: we do not use it, we tell the customer, and we delete it on their instruction.

Phishing-simulation results and training completion records are not special category data, but they are behavioural data about identifiable employees and can be used in ways that affect them. We treat them with corresponding care and address them specifically in section 16.

14 Where we act as processor Processor

Everything in sections 14 to 17 concerns personal data that belongs, in data protection terms, to our customer. They are the controller. We process it only on their documented instructions.

14.1 What this means for you if you are an affected individual

If you are an employee of one of our customers, or a contact at one of their suppliers, and personal data about you is in our platform, then:

• the organisation that put it there is responsible for telling you about it and for having a lawful basis;
• if you want to exercise a right — access, erasure, objection — you should approach that organisation, not us;
• if you approach us anyway, we will not ignore you. We will tell you that we act as a processor, tell you which organisation the data belongs to if we are permitted to, and pass your request to them promptly. We will not action the request ourselves unless the controller instructs us to.

14.2 Categories of processor data

Lawful basis is not stated in the table above because it is not ours to state. The controller determines the lawful basis for each of these processing operations.

15 Security-scanning data specifically Processor

This section exists because “we scan your cloud environment” is an alarming sentence if it is not qualified, and because a vague answer would be worse than no answer.

15.1 What a configuration scan reads

A scan reads settings and metadata. It requests configuration objects from the tenant’s administrative API: conditional access and authentication policies, directory role assignments, account existence and multi-factor enrolment state, group membership, external sharing and guest access settings, mail transport and forwarding rules, anti-malware and anti-phishing policy state, audit log configuration and retention settings, and — once the Azure connector is written — resource configuration and network exposure settings.

A scan does not read the contents of files, documents, spreadsheets or presentations in SharePoint, OneDrive or Google Drive; the bodies, subjects or attachments of email; chat or Teams message content; database contents; application data; secret or key values; passwords or password hashes. It does not download, copy, index or preview customer documents. Where an administrative API returns a filename or a mailbox address as an incidental part of a configuration object, that identifier may appear in the evidence record; the underlying object is not retrieved.

Where an API response contains more than the check requires, the surplus is discarded before the evidence record is written, rather than stored and filtered afterwards.

15.2 Least-privilege scopes

We request the narrowest scopes that let a check run, and every scope we request is read-only. There are no write scopes on the list and there will not be: the platform cannot change a setting, disable an account, quarantine a message or remediate a finding in your tenant. A compliance tool with write access to its customers’ identity providers is an unusually attractive target, and we have chosen not to be one.

The current scope list is published on the evidence page and includes, for Microsoft Graph, Policy.Read.All, Directory.Read.All, Organization.Read.All, AuditLog.Read.All and SharePointTenantSettings.Read.All; and for the Google Admin SDK, the read-only directory, domain and role-management scopes. Any change that widens what we can read will be notified to connected customers before it takes effect, and will require the customer to grant the wider consent themselves.

15.3 Credentials

Tenant credentials, refresh tokens and service account keys are stored encrypted at rest using authenticated encryption, with keys held in a managed key service separate from the application database. They are decrypted only in memory at the point a scan runs, and only for the tenant that granted them.

You can revoke our access at any time, from your own admin console, without asking us and without notice. Revoking consent in your identity provider stops all scanning immediately. It does not delete evidence records already written — those remain in your account, subject to your retention settings, until you delete them or ask us to.

15.4 Findings are never shared between customers

Scan results, findings, failure counts and posture data belong to the customer whose tenant they came from. They are logically separated per tenant and are not pooled, aggregated, benchmarked, anonymised into an industry dataset, published in a report, used as marketing material or used to train machine-learning models. We do not produce a “how you compare to your peers” feature, because building one would require exactly the cross-customer use of findings that we are undertaking not to do.

15.5 What a scan cannot tell you

A scan is a point-in-time reading of configuration. It does not detect intrusion, does not monitor traffic, does not inspect endpoints, and does not tell you whether you have been breached. Nothing in the platform is a security monitoring or incident detection service, and it should not be relied on as one.

16 Evidence, policy, supplier and training records Processor

16.1 Evidence records

Evidence records are append-only. Corrections are written as superseding records that reference the original, and both remain visible with their timestamps. This is deliberate — an evidence trail that can be silently rewritten is not evidence — but it has a consequence worth stating: correcting an inaccuracy in an evidence record produces a new record rather than an edit to the old one, and the old record remains until deletion or expiry.

Where a controller instructs us to erase personal data under Article 17, we erase the record itself rather than writing a superseding one. Erasure removes the record from the store and from backups on the backup rotation cycle described in section 20.

16.2 Policy documents and acknowledgements

A policy acknowledgement record names an individual and states that they marked a specific version of a document as read on a specific date. That is personal data about the employee, held by the employer for an accountability purpose. We store it and make it available; we do not evaluate it.

16.3 Supplier questionnaires

When a customer issues a questionnaire, an individual at their supplier receives an email from our system and submits a response. We process that individual’s name, work email and answers as processor for the customer who sent it. We do not use supplier contact details for our own purposes, do not market to them, and do not build a supplier database across customers.

16.4 Training and phishing-simulation records

Phishing simulation produces personal data about how a named employee behaved when tested. It is the most sensitive processor data the platform will hold, and it is easy to build something punitive out of it.

Our design position, which we will hold customers to contractually: results are surfaced at cohort level by default; individual results exist to trigger follow-up training rather than sanction; and the platform records the identity of anyone who views individual results. An employer who wants to use individual results for disciplinary purposes must configure that deliberately, and the fact that they did so is itself recorded. We cannot control what an employer does with data it lawfully holds, but we can decline to make the punitive path the default one.

Simulated phishing emails are sent to the customer’s own staff at the customer’s instruction. They are not marketing and are not sent to anyone outside the customer’s organisation.

17 Article 28 processor commitments Processor

Where we act as processor we do so under a written contract meeting Article 28(3) UK GDPR. Our standard data processing terms form part of our terms and commit us to the following.

17.1 Documented instructions — Art. 28(3)(a)

We process personal data only on the controller’s documented instructions, including in relation to transfers outside the UK, unless required to do otherwise by law — in which case we will inform the controller of that legal requirement before processing, unless the law prohibits us from doing so on important grounds of public interest. If we consider an instruction infringes UK GDPR or the DPA 2018, we will say so.

17.2 Confidentiality — Art. 28(3)(b)

Everyone we authorise to process personal data is bound by a written confidentiality obligation that survives the end of their engagement, and is granted the least access needed to do their work.

17.3 Security — Art. 28(3)(c)

We implement the technical and organisational measures set out in section 21, and will implement further measures required by Article 32 as the service matures. We describe those measures honestly, including where they are not yet in place.

17.4 Sub-processors — Art. 28(2) and 28(4)

We engage sub-processors only under a written contract imposing the same data protection obligations we owe the controller. We maintain the list in section 18. We operate general written authorisation: we will give at least 30 days’ notice by email to the customer’s nominated contact before adding or replacing a sub-processor, and the customer may object on reasonable data protection grounds within that period. If we cannot resolve a reasonable objection, the customer may terminate the affected service without penalty and receive a refund of any prepaid fees for the unused period. We remain fully liable to the controller for our sub-processors’ performance.

17.5 Assisting with data subject rights — Art. 28(3)(e)

Taking into account the nature of the processing, we assist the controller by appropriate technical and organisational measures in responding to data subject requests. In practice this means the platform lets an administrator find, export and delete the records relating to a named individual, and where it cannot, we will do it manually within a reasonable period at no charge for a proportionate number of requests.

17.6 Assisting with Articles 32 to 36 — Art. 28(3)(f)

We assist the controller in ensuring compliance with the security, breach notification, data protection impact assessment and prior consultation obligations, taking into account the nature of processing and the information available to us. We will provide the information a controller reasonably needs to complete a DPIA covering their use of the platform.

17.7 Deletion or return — Art. 28(3)(g)

At the controller’s choice, we delete or return all personal data at the end of the provision of services and delete existing copies, unless law requires storage. Our default is deletion 30 days after termination, with an export made available during that window. Backups are purged on the rotation described in section 20.

17.8 Audit and information — Art. 28(3)(h)

We make available the information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by the controller or an auditor they mandate. In practice we expect this to be satisfied by a written security questionnaire and documentation; we will accommodate a reasonable on-site or remote audit no more than once a year, on reasonable notice, at the controller’s cost, subject to confidentiality and to not compromising other customers’ security.

We cannot offer a SOC 2 report or an ISO 27001 certificate in place of an audit, because we hold neither.

17.9 Breach notification to the controller — Art. 33(2)

We notify the controller without undue delay after becoming aware of a personal data breach affecting their data, and in any event within 24 hours of becoming aware, with the information available to us at that point and further information as it becomes available. Twenty-four hours is a commitment we make so that the controller has time to meet their own 72-hour obligation to the ICO.

18 Sub-processors Controller & processor

The following organisations process personal data on our behalf. The list is short because the company is small and pre-launch, and we intend to keep it short.

18.1 Named providers and honesty about the gaps

Three rows above say “to be confirmed”. That is accurate: the company is pre-launch, there is no production platform and no billing. We would rather publish an honest gap than name a provider we have not contracted with. Each will be named in this table, with its processing location and transfer safeguard, before any personal data reaches it.

18.2 Change notification

We will notify customers by email to their nominated contact at least 30 days before adding or replacing a sub-processor that processes their data, and will publish the change in this table on the same day the notice goes out. The objection and termination rights in section 17.4 apply.

18.3 Google Fonts

Google is not a sub-processor for us in respect of fonts, because we do not send it any data. Your browser fetches the font files directly and Google receives your IP address as an independent controller of that interaction. Section 5.1 covers this.

19 International transfers Controller & processor

Our intention is that customer platform data is stored and processed in the United Kingdom or the Republic of Ireland. Some processing nonetheless involves a transfer outside the UK, principally through global content-delivery networks and the US parent companies of service providers.

19.1 The legal mechanisms we use

Adequacy regulations

Where personal data goes to a country covered by UK adequacy regulations under Article 45 UK GDPR and section 17A DPA 2018 — which includes the EEA, and therefore Ireland — no additional safeguard is required. Transfers to the United States may rely on the UK Extension to the EU–US Data Privacy Framework where the recipient is certified under it and the transfer is within the scope of its certification.

International Data Transfer Agreement

Where there is no adequacy cover, we use the ICO’s International Data Transfer Agreement (IDTA) as an Article 46(2) safeguard, or the UK International Data Transfer Addendum to the EU Standard Contractual Clauses where the recipient already operates the EU SCCs. Our contract with Cloudflare relies on the UK Addendum.

Transfer risk assessments

Before relying on the IDTA or the UK Addendum we carry out a transfer risk assessment following the ICO’s approach: we consider the nature and sensitivity of the data, the destination country’s legal framework and the practical likelihood of government access, whether the safeguard would be enforceable in practice, and what supplementary measures reduce residual risk. Supplementary measures we use or expect to use include encryption in transit and at rest, keeping key material within the UK or EEA, minimising what is transferred, and contractual commitments to challenge and notify unlawful access requests where legally permitted.

Where a transfer risk assessment concludes that the risk cannot be reduced to an acceptable level, we do not make the transfer. We would rather change provider than paper over a transfer we cannot defend.

19.2 Your right to see the safeguards

You can ask for a copy of the transfer mechanism relied on for any specific transfer by writing to hello@lagancyber.co.uk. We may redact commercially confidential pricing terms, but not the data protection provisions.

19.3 Instructions from controllers

Where we act as processor, we transfer personal data outside the UK only on the controller’s documented instructions or where required by law. A customer who requires that no data leaves the UK should tell us before connecting a tenant, and we will tell them honestly whether we can meet that requirement with our current infrastructure.

20 Retention Controller & processor

We keep personal data no longer than necessary. “Necessary” needs a reason, so every row below has one.

20.1 Backups and deletion

When we delete personal data from live systems, copies may persist briefly in encrypted backups. Those backups are not used for any purpose other than disaster recovery, are not searched for deleted records, and rotate out within 35 days. If a backup were restored for disaster recovery, we would re-apply outstanding deletions to the restored dataset. We state this rather than claiming instant total erasure, because instant total erasure across backups is not how backup systems work.

21 Security measures, stated honestly Controller & processor

21.1 Measures in place

• Transport encryption: TLS 1.2 or above for all connections to our website and platform, with HTTP Strict Transport Security.
• Encryption at rest for the application database, object storage and backups.
• Tenant credentials and refresh tokens encrypted with authenticated encryption, with key material held in a managed key service separate from the application database.
• Read-only, least-privilege API scopes for every cloud connector; no write scopes requested or held.
• Logical separation of customer data by tenant, with authorisation checks on every request rather than at the session boundary only.
• Multi-factor authentication required for all administrative access to our infrastructure and code repositories.
• Access on a least-privilege basis, reviewed when a person’s role changes and revoked when they leave.
• Append-only evidence storage with content hashing, so unauthorised modification of a record is detectable.
• Audit logging of access to customer data, retained 13 months.
• Dependency and vulnerability scanning in our build pipeline, with patching prioritised by severity.
• Encrypted, tested backups with a documented restore procedure.
• Written confidentiality obligations for everyone with access to personal data.
• A documented breach response procedure — section 22.

21.2 Measures not in place

Stating what is missing is more useful than a longer list of what is present.

• No ISO 27001, SOC 2 or Cyber Essentials certification.
• No independent penetration test of the platform has been carried out.
• No 24/7 security operations centre or on-call rota. We are a very small company and outside working hours the response is best-effort.
• No formal, externally audited information security management system, though the internal control set is documented.
• No bug bounty programme. Disclosures are welcome and unpaid — see the status page.
• No published uptime service level, because there is no production service.

21.3 Proportionality

Article 32 requires measures appropriate to the risk, taking into account the state of the art, cost of implementation, and the nature, scope, context and purposes of processing. We hold sensitive information about other organisations’ security weaknesses, so the risk is high and the bar is correspondingly high. Where our measures do not yet meet that bar, the honest answer is that we are pre-launch and building towards it — not that the bar is lower than it is.

22 Personal data breaches Controller & processor

22.1 What counts

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It is not only hacking: a mis-sent email, a lost laptop, a mis-configured permission or an unrecoverable deletion can all qualify.

22.2 Our process

1. Detect and contain. Anyone in the company who suspects a breach reports it immediately to the Data Protection Lead. Containment takes priority over analysis.
2. Assess. We establish what data, whose data, how much, what the likely consequences are, and whether the data was encrypted or otherwise unintelligible to the recipient.
3. Record. Every breach is recorded in our internal breach register with the facts, effects and remedial action, whether or not it is reportable. This is required by Article 33(5) regardless of reportability.
4. Notify the ICO where required. Where we are controller and the breach is likely to result in a risk to the rights and freedoms of individuals, we notify the Information Commissioner without undue delay and, where feasible, within 72 hours of becoming aware, under Article 33(1). If we notify later than 72 hours we give reasons for the delay. If we conclude a breach is not reportable, we record why.
5. Notify affected individuals where required. Where the breach is likely to result in a high risk to individuals, we tell them without undue delay under Article 34, in plain language, describing the likely consequences and the measures taken, and giving a contact point. We may not need to if the data was encrypted to a standard that makes it unintelligible, if we have taken measures that mean the high risk is no longer likely to materialise, or if individual notification would involve disproportionate effort — in which case we will make a public communication instead.
6. Notify the controller where we are processor. Within 24 hours of becoming aware, per section 17.9. We do not notify the ICO on a controller’s behalf unless instructed; that decision is theirs.
7. Learn. Every breach produces a written post-incident review with actions and owners.

22.3 Reporting something to us

If you think we have suffered a breach, or that we have exposed data we should not have, tell us at hello@lagancyber.co.uk. We acknowledge within two working days. We will not threaten legal action against anyone who reports a genuine security issue to us in good faith and does not exploit it, exfiltrate data or disclose it publicly before we have had a reasonable opportunity to fix it.

23 Your rights under UK GDPR Controller

These rights apply where we are the controller. Where we are processor, direct your request to the organisation that controls the data — see section 14.1.

23.1 The right to be informed — Articles 13 and 14

You have the right to be told what we do with your personal data, why, on what basis, who receives it and how long we keep it. This notice is how we discharge that. Where we obtain personal data from someone other than you — for example a colleague giving us your work email as a contact — we will tell you within a month of obtaining it, or at first communication with you, unless you already have the information.

23.2 The right of access — Article 15

You can ask whether we process personal data about you and, if so, receive a copy along with the supplementary information in Article 15(1): purposes, categories, recipients, retention, your rights, the source, and any automated decision-making. We respond within one month, extendable by two further months for complex or numerous requests, in which case we will tell you within the first month and explain why. The first copy is free. We may charge a reasonable administrative fee for further copies of the same information, or refuse a request that is manifestly unfounded or excessive — and if we do, we will explain why and tell you how to complain.

Where providing a copy would adversely affect the rights and freedoms of others — for example by disclosing a third party’s personal data — we will redact rather than refuse where redaction is possible.

23.3 The right to rectification — Article 16

If personal data we hold about you is inaccurate, you can require us to correct it, and if it is incomplete you can require us to complete it, including by providing a supplementary statement. We will also tell each recipient the data was disclosed to, unless that proves impossible or involves disproportionate effort.

23.4 The right to erasure — Article 17

You can require erasure where the data is no longer necessary for the purpose, where you withdraw the consent it relied on and there is no other basis, where you object under Article 21(1) and there is no overriding legitimate ground, where you object to direct marketing, where the data has been unlawfully processed, or where erasure is required by law.

The right does not apply where processing is necessary for compliance with a legal obligation — most obviously our statutory accounting records — or for the establishment, exercise or defence of legal claims. Where we cannot erase, we will tell you which exemption applies and to which data, and erase everything else.

23.5 The right to restrict processing — Article 18

You can require us to stop using data while a dispute is resolved: while we verify accuracy you have contested, where processing is unlawful but you prefer restriction to erasure, where we no longer need the data but you need it for a legal claim, or while we consider an objection under Article 21(1). Restricted data is stored but not otherwise used, and we will tell you before restriction is lifted.

23.6 The right to data portability — Article 20

Where processing is based on consent or on a contract and is carried out by automated means, you can receive the personal data you provided to us in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible. We provide exports in JSON and CSV.

23.7 The right to object — Article 21

You can object at any time, on grounds relating to your particular situation, to processing based on legitimate interests. We will stop unless we demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or the processing is for legal claims. Your right to object to direct marketing is absolute and unconditional; we will stop immediately and permanently.

23.8 Rights related to automated decision-making — Article 22

You have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning you or similarly significantly affects you. See section 27 for our position.

23.9 The right to withdraw consent — Article 7(3)

Where we rely on consent, you can withdraw it at any time and it must be as easy to withdraw as it was to give. Withdrawal does not affect the lawfulness of processing before withdrawal.

23.10 The right to complain — Article 77

You can complain to the Information Commissioner at any time. See section 25. You do not have to complain to us first, though we would rather you did so we can put it right.

24 Exercising your rights Controller

24.1 How to ask

Write to hello@lagancyber.co.uk or to the registered office. You do not need to use a particular form of words, cite an article, or use the phrase “subject access request”. Telling us what you want in plain English is enough. It helps if you say which right you are exercising and give us enough information to find your data.

24.2 Identity verification

We will ask for enough information to be satisfied of your identity before we disclose personal data. What we ask for will be proportionate — usually confirmation from the email address we already hold. We will not demand a passport scan to answer a question about an email enquiry, and we will not collect more identity data than the request justifies. Where you act for someone else, we will ask for evidence of your authority.

24.3 Timescales

We acknowledge requests within five working days and respond substantively within one month of receipt, or of receiving the information needed to verify your identity. We can extend by two further months where the request is complex or where you have made a number of requests; we will tell you within the first month if we do, and explain why.

24.4 Fees

There is no fee. We may charge a reasonable fee based on administrative cost, or refuse, where a request is manifestly unfounded or excessive, particularly if repetitive. If we refuse we will explain why, tell you about your right to complain to the ICO and your right to a judicial remedy, and do so within one month.

24.5 If your request concerns processor data

If the data you are asking about sits in a customer’s account, we will tell you so, identify the controller if we are permitted to, and forward your request to them without undue delay. We will not action it ourselves without their instruction, because doing so would breach our Article 28 obligations to them.

25 Complaints and the ICO Controller & processor

If you are unhappy with how we have handled your personal data or a request, tell us first at hello@lagancyber.co.uk. We acknowledge within five working days and aim to give a substantive answer within 20 working days, or tell you why we need longer.

You have the right to complain to the supervisory authority at any time, without going through us first. In the United Kingdom this is the Information Commissioner’s Office.

If you are in the Republic of Ireland or elsewhere in the EEA and consider the EU GDPR applies to processing by us, you may also complain to your local supervisory authority — in Ireland, the Data Protection Commission. You also have the right to an effective judicial remedy under Article 79 UK GDPR and to compensation for damage under Article 82.

26 Children’s data Controller & processor

Our website and our platform are business tools directed at organisations. They are not directed at children, are not designed to appeal to children, and offer nothing a child would want. We do not knowingly collect personal data from anyone under 18, and we do not offer information society services directly to children within the meaning of Article 8 UK GDPR — so the age-of-consent provisions in section 9 DPA 2018 do not arise.

Because our services are not directed at or likely to be accessed by children, the ICO’s Age Appropriate Design Code does not apply to them. We keep that assessment under review, and it would change if we ever built a consumer-facing product.

If we become aware that we hold personal data relating to a child, we will delete it promptly unless there is a clear lawful reason to keep it. If you believe we hold data about a child, tell us at hello@lagancyber.co.uk.

Where a customer’s use of the platform would involve children’s data — for example an education-sector customer enrolling under-18 staff or students in awareness training — the customer is the controller and is responsible for the lawful basis and for any age-appropriate design obligations. We would expect to be told before such a deployment.

27 Automated decision-making and profiling Controller & processor

We do not carry out automated decision-making that produces legal effects concerning you or similarly significantly affects you within the meaning of Article 22(1) UK GDPR.

Some qualification is worth giving, because a platform full of automated checks invites the question.

27.1 What the platform automates

Configuration checks are automated: the platform reads a setting and records whether it meets a rule. That produces a finding about an organisation’s configuration, not a decision about a person. Where a finding names an individual — “two privileged accounts are excluded from the MFA policy” — it is a factual statement about an account’s configuration, and any consequence for the account holder follows from a human at their employer deciding what to do about it.

27.2 Training and phishing results

Training completion and phishing-simulation results describe how a named person behaved. The platform records the result and can assign follow-up training automatically. Automatic assignment of a short training module does not, in our assessment, produce a legal effect or similarly significantly affect someone. Any decision that would — disciplinary action, performance assessment, changes to employment — is taken by the employer, by a human, using the record as one input. We will say so in our contracts and we will not build a feature that automates a disciplinary outcome.

27.3 Profiling

We do not profile website visitors, do not build behavioural profiles for marketing, and do not score individuals. We do not use personal data to train machine-learning models, whether our own or a third party’s.

27.4 If this ever changes

If we ever introduce processing within Article 22(1), we will identify a permitted ground under Article 22(2), publish it here before deployment, explain the logic involved and the significance and envisaged consequences, and implement suitable safeguards including the right to obtain human intervention, to express your point of view and to contest the decision.

28 Cookies and local storage Controller

This website sets no cookies of its own, uses no analytics or advertising cookies, and stores nothing in your browser’s local storage or session storage. The only cookie that may be set is a strictly necessary security cookie from our content delivery provider, which falls within the exemption in regulation 6(4) PECR and does not require consent — which is why you are not being asked to dismiss a banner.

The cookie policy gives the full detail, including a table of every cookie, per-browser control instructions, and our position on Do Not Track and Global Privacy Control.

When the platform launches it will use a strictly necessary session cookie for authentication and may store user-interface preferences in local storage. Neither requires consent. If we ever introduce anything that does — analytics, product telemetry, anything third-party — we will implement a compliant consent mechanism that asks before setting, makes refusing as easy as accepting, and lets you change your mind. We will not deploy it first and update the policy afterwards.

29 Marketing and electronic communications Controller

We do not operate a mailing list, do not send a newsletter, and do not run automated email sequences. We have no marketing database.

If that changes, we will comply with PECR and UK GDPR: marketing email to individual subscribers and sole traders only with prior consent, or under the soft opt-in in regulation 22(3) where we obtained the address in the course of a sale or negotiations for a sale of a similar product, gave a free means of refusal at the time, and give one in every message. Every marketing message will identify us, give a working unsubscribe route, and honour an unsubscribe promptly.

Transactional and service messages — an alert that a scan failed, a notice of a sub-processor change, a security notification, a billing message — are not marketing and will continue for as long as you hold an account, because they are part of providing the service.

We do not make marketing telephone calls, send marketing SMS, or use third-party marketing lists. We do not sell, rent or share personal data with anyone for their own marketing.

30 Mobile applications Controller

30.1 Permissions

Our design position is that an app for reviewing compliance evidence needs almost no device access. The table sets out the only permissions we anticipate requesting.

We will not request location, contacts, calendar, microphone, health data, SMS, call logs, or background location. If a future feature genuinely required one, we would request it contextually at the point of use, explain why, and make it optional.

30.2 Analytics and crash data

Our position is that mobile analytics should be opt-in and minimal. If we ship an app, crash reporting will be offered as an explicit choice at first run rather than defaulted on, with a plain description of what a crash report contains: the app version, device model, operating system version, a stack trace, and the sequence of screens leading to the crash. Crash reports will not contain evidence records, customer data, or the contents of anything you were viewing.

We will not embed advertising SDKs, attribution SDKs, session-recording SDKs or social media SDKs. There is no advertising in a compliance product and no reason for those libraries to exist in it.

30.3 Identifiers

We will not use the iOS Identifier for Advertisers (IDFA) or the Android Advertising ID, and will not request tracking permission for advertising purposes. Where a per-installation identifier is needed to route a push notification or associate a crash report, it will be an identifier we generate, scoped to our app, reset when the app is reinstalled, and not shared with anyone.

30.4 iOS App Tracking Transparency

App Tracking Transparency requires an app to request permission before tracking a user across apps and websites owned by other companies, or accessing the device advertising identifier. We do not track across apps or websites and do not access the advertising identifier, so no ATT prompt will be shown. If we ever did anything requiring one, we would present the prompt honestly and would not degrade the app for anyone who declined.

30.5 Google Play Data Safety

The Data Safety declaration on any Google Play listing we publish will match this notice. Where they appear to differ, treat it as an error and tell us. We commit that the declaration will state: no data shared with third parties for advertising; data collected limited to account information, app activity and optional diagnostics; data encrypted in transit; users can request deletion. We will keep the declaration current when the app changes rather than at annual review.

30.6 Store-billed subscriptions

If we sell subscriptions through the App Store or Google Play, the store processes the payment as merchant of record. We receive confirmation that a subscription is active, its term and its renewal state; we do not receive your card details. Apple and Google each act as independent controllers for the payment data they hold, under their own privacy policies.

Store-billed subscriptions renew automatically until cancelled, and cancellation is managed in your Apple or Google account rather than by us — we cannot cancel a store subscription for you. Refunds for store-billed purchases are handled under the store’s own policy. Section 31 explains the difference between cancelling a subscription and deleting an account: they are not the same thing, and doing one does not do the other.

31 Account and data deletion Controller & processor

You should be able to leave. This section says exactly how, and it applies to any future mobile application as well as to the web platform — app stores require a deletion route to be available and discoverable, and so do we.

31.1 In-app and in-product route

Where you hold an individual account, deletion will be available from within the product itself, without contacting support and without a retention call: Settings → Account → Delete account. The same path will exist in the web application and in any mobile application. You will be shown, before you confirm, what will be deleted, what will be retained and why, and whether deleting your individual account also deletes organisational data (it does not — see 31.4).

31.2 Email route

You can also request deletion by writing to hello@lagancyber.co.uk with the subject “Account and data deletion”. We acknowledge within five working days and verify your identity proportionately, normally by confirming from the address on the account.

31.3 What happens and how long it takes

We complete deletion within 30 days of a verified request. In practice live-system deletion happens within a few working days; the 30-day commitment covers backups rotating out, per section 20.1. We will confirm in writing when it is done, tell you if anything has been retained, and say under which legal obligation.

31.4 Deleting an organisation’s data

If you are an administrator and want the whole account and all its data removed, that is a controller instruction under Article 28(3)(g), not an individual right. An administrator can request full tenant deletion by email; we will verify authority, make an export available, and delete within 30 days of the export window closing. Default behaviour on termination is deletion 30 days after the contract ends.

An individual employee cannot delete their employer’s evidence records, and we would not action such a request without the controller’s instruction. If you want personal data about you removed from an employer’s account, ask the employer.

31.5 What we keep, and why

Two categories survive deletion: statutory accounting records for six years, and audit log entries until the 13-month period expires. Both are legally justified and both are stated above rather than buried. Nothing else is retained. We do not keep a “suppression list” of deleted users, because we do not do marketing.

31.6 Cancelling a subscription is not deleting an account

Cancelling a subscription stops billing. Deleting an account removes your data. If you want both, do both. If your subscription is store-billed, cancel it in your Apple or Google account — we cannot do it for you — and request deletion from us separately.

32 Changes to this notice Controller & processor

This is version 1.0, effective 5 August 2026. It is the first version.

We will update it when our processing changes — when a sub-processor is named, when the platform launches, when an app is published. For any change that materially affects how we handle your personal data or reduces your protections, we will give at least 30 days’ notice by email to account holders before it takes effect, in addition to publishing it here. Minor corrections take effect on publication.

Superseded versions are available on request from hello@lagancyber.co.uk, so that you can see what changed and when.

← Back to Lagan Cyber