ScanHawk^™

Terms of Service Acceptable Use Policy Privacy Policy

Privacy Policy

Version 3.2.0 · Effective October 29, 2026 · Last updated October 29, 2026 · Replaces the version dated October 28, 2026

1. Who we are

ScanHawk is a product of TwentyPin, Inc., 2750 FM 1463 Road, Suite 150-70, Katy, TX 77494, which is the controller of the personal data described here. Contact us at privacy@twentypin.com.

2. What this policy covers

This policy covers every ScanHawk surface: the iOS and Android app, the installable web app (PWA), the browser extension, the Microsoft Outlook add-in, the scanhawk.io website, and the ScanHawk engine and API. Where a surface behaves differently, we say so. If your employer or another organisation enrolled you in ScanHawk rather than you installing it yourself, §14 describes what is different; if you installed it yourself, §14 does not apply to you.

3. What we collect

3.1 The contents of what you check

When you scan a QR code or check a link, we receive the decoded text — in almost every case a URL. We also receive a short context label (for example generic, email, or parking_meter) describing where the code was found.

A URL can itself contain personal information — a name in a path, an email address in a query string, or a single-use token in a password-reset or document-sharing link. We do not seek that information, but we necessarily receive whatever the URL contains. Our Acceptable Use Policy asks you not to submit links carrying other people’s secrets.

Some codes are themselves a credential. The QR code that enrols an authenticator app (an otpauth:// or otpauth-migration:// link) carries the shared secret for your two-factor codes in clear text. Keeping one would not be a log entry; it would be a standing compromise of that account, and one that survives a password change. So we strip the secret out of these payloads on arrival — before the check is written to our logs, before the result is returned to you, and before anything reaches our threat feed. What is kept is the harmless part that makes the record reviewable: the scheme, the issuer, the account label, and the algorithm. We necessarily receive the code in order to check it; we simply do not keep the secret in it.

3.2 Your installation identifier

On first launch the app generates a random identifier (a version-4 UUID) and stores it on your device. It is not derived from your device, your hardware, your advertising ID, or you; it does not follow you across apps; and reinstalling the app produces a new one. We use it for three things: attaching your acceptance of our terms to something; applying rate limits fairly so one installation cannot exhaust the service for everyone; and remembering whether this installation has ScanHawk Pro (§3.12), whether bought or provided by an organisation’s access code.

Where ScanHawk Pro is on sale (on iOS, from the release that sells it), the app also registers on first launch with our server, which issues it a random installation secret. The secret lives in your device’s secure keychain and is sent with requests that need to prove they come from your installation and not from someone who merely learned your identifier — confirming a subscription or an organisation’s access code. Elsewhere the app registers only when you redeem an access code or already hold Pro. We keep only a one-way hash of the secret, together with which platform you are on and when the installation was last seen. If the secret is lost (for example when you erase the app’s data), the app simply registers again; a subscription re-attaches through the store record described in §3.12.

The browser extension uses an equivalent anonymous install token, which it requests from our worker automatically on first run.

3.3 Your record of acceptance

When you accept the Terms of Service and Acceptable Use Policy, we store a consent record containing your installation identifier, the version number and a SHA-256 hash of each document you were shown, the fact that you scrolled to the end before agreeing, the time you accepted, and the app version, platform, and locale. The document hash is what lets us show precisely which text you agreed to, rather than merely which version number.

3.4 Your contact details — optional

You may give us an email address, a phone number, or both, to hear from us about ScanHawk. This is optional and is never required to use ScanHawk. It is a separate choice from accepting the terms: declining changes nothing about your access. There are two places you can do this: the product-news signup on our launch page, and the Tell me more about… form on our home page. Our early-access waitlist asks for more than these two and is described on its own in §3.11.

The home-page form also asks which topics you want to hear about (the app, the Microsoft 365 add-in and browser extension, the API, pricing, or all of them) and, if you tick Something else, lets you type a short note. We keep only what you entered: the contact details you gave, the boxes you ticked, and the note. We do not record which device or browser you used, and we do not combine this with any scan you have run.

We use these details for one thing: to send you the information you asked for, about the topics you ticked. We do not sell or share them. Every email carries an unsubscribe link, and you can also unsubscribe or ask us to delete your details by emailing us (§10). We do not currently send text messages. If we start, a message will only go to a number given on that form, we will name the messaging provider in §7 before the first message is sent, standard message and data rates may apply, and replying STOP to any text ends them.

The note is free text you typed, so we treat it as untrusted: it is stored as plain text, read by a person, never displayed as a web page, and never used to make an automated decision about you. Please do not put passwords, account numbers, or anyone else's personal details in it.

3.5 Operational logs

We log each check — the submitted text (redacted as described in §3.1), the resolved destination, the resulting verdict and risk score, the context label, the signals and redirect chain behind the verdict, and the time — to operate the service, cache results, detect abuse, and strengthen our threat feed. These records carry no installation identifier. They are not linked to you or to your installation, and we cannot work backwards from one to the other. Each check does record which credential submitted it: for the app, the extension, and the add-in that is one of our own service keys, so it tells us which route the check took through our infrastructure — not who you are. If you call the engine under your own API key, the check is recorded against your account so that we can support and bill it.

Separately, we keep a daily count of how many checks each installation has made, so that the rate limit described in §3.2 can work, and a separate daily count of Deep Checks (§3.13) so that allowance can work too. Each counter holds only the installation identifier, the date, and a number — never the text you checked or the verdict you were given.

We also record standard server logs for security, rate limiting, and to understand how our website and services are used. A log entry holds the IP address the request came from, the time, what was requested, the response, and the browser’s self-description (its user agent). We keep these logs in storage we control and delete them automatically after 30 days (§8). We use them in aggregate — how many visits a page received, whether that number is rising — and we do not use them to build a profile of you or to follow you between visits.

3.6 Reports you choose to submit

If you report a code or link, the URL and your reported verdict are added to our community threat feed to protect other users. Threat feed entries are indicators about destinations and are not linked to your identity. Reporting a problem with the app itself is a different thing and goes somewhere different — see §3.10.

3.7 App update checks

The app can receive fixes to its own software without waiting for an app-store release. Because ScanHawk’s job is to be right about a link, we want a wrong answer to be fixable in minutes rather than in the days an app-store review takes.

The check runs only after you check a code or link and we reach our service — never when you open the app, and never before you have asked for anything. If you are offline, or the app answered you without the network, no update request is made. It runs at most once each time you open the app, and it never interrupts a result you are reading: anything downloaded is applied the next time the app starts.

The request goes to Expo (650 Industries, Inc.), which hosts our software updates. It carries no scanned content, no URL you checked, and no verdict. It carries which platform you are on, which version of the app you are running, and a separate random identifier generated by the update service and stored on your device. That identifier is not the installation identifier described in §3.2, is not shared with us for any other purpose, and like the one in §3.2 it is not derived from you or your hardware and does not follow you across apps. Expo processes it to serve the correct update and to operate the service. It is not analytics, and we do not receive a profile, an audience, or any behavioural data from it.

3.8 The website

scanhawk.io is a static site. It sets no cookies, runs no analytics, and loads no third-party scripts or fonts — everything it serves is first-party. Nothing in your browser reports on what you do.

We do count visits, and we want to be exact about how, because “we count page views” and “we run no analytics” can look like a contradiction. The counting happens on our side, afterwards, from the server logs described in §3.5 — the same records any web server keeps. Nothing is added to the page you load, no identifier is stored on your device, and there is no third party watching alongside us. What we can see is that a page was requested by an address at a time; what we cannot see is who you are, or that the person who read one page yesterday is the person reading another today.

3.9 When you contact us

If you email one of the addresses in §15 — or info@, hr@, or abuse@ at twentypin.com — we receive whatever you send: your name and email address, your message, and any attachments. It is kept in our company mailbox and used to answer you.

We are a small company, so we use an AI assistant (Anthropic's Claude, §7) to help us sort incoming mail and draft replies. A person reads every message, and a person reviews every reply before it is sent. The assistant sees the subject and the text of your message with your email address removed; it does not see your address or your attachments, and it does not send anything. If we ever let it send routine replies on its own, we will say so here first. The assistant makes no decision about you: it suggests, and a person decides.

Three kinds of message are handled with extra care. Messages to hr@ are never evaluated, summarised, or ranked by the assistant — it only tells us a message has arrived, and a person reads it in full. Messages to security@ are handled under our vulnerability-disclosure process, by a person. Messages to privacy@ are treated as requests under §10 from the moment they arrive.

We keep a short working record of each message — what kind of message it was, the draft the assistant proposed, and whether we sent it as-is or changed it — so we can check the assistant's work. That record holds your domain and a one-way hash of your address, not the address itself, and is deleted after 90 days.

3.10 Problem reports you send from the app

Under About → Report a problem you can tell us that something in the app is not working. We keep what you type, an email address only if you choose to give one so we can reply, and a small amount of information about the app and device so we can reproduce the problem: the app version and build, the operating system and its version, your language setting, which update of our software the app is running, and which screen you were on. The report is stored against the installation identifier in §3.2 so that the in-app erase (§10) can remove it.

Nothing you have scanned or checked is included — no code, no link, no verdict. The form has no field for one, and our server keeps only the items listed above. The report is emailed to us through Postmark (§7) and read by a person. What you typed is treated as untrusted text: stored as plain text, never displayed as a web page, and never used to make an automated decision about you. Please do not put passwords, account numbers, or anyone else's personal details in it. This is separate from Report this link (§3.6), which is about a destination, not about the app.

If the app stops unexpectedly. ScanHawk keeps the error that stopped it, on your device. The next time you open the app it asks you once — under the heading “ScanHawk closed unexpectedly” — whether to send that one error to us. Nothing leaves your device unless you choose Send. The question is asked once per crash and never repeated: the stored record is deleted before you are asked, so declining ends it, and so does ignoring it. If you do send it, we receive the error message, the sequence of calls inside our own software that led to it (file and line in our code), the time it happened, the app version and build, and which update of our software was running. No email address is attached.

An error message can quote whatever the app was working on when it failed, which could be something you scanned. So before the record is written to your device at all — let alone sent — we remove web addresses, bare host names with a path, email addresses, the prefixes QR codes use to carry other kinds of payload (otpauth:, WIFI:, mailto:, tel: and the rest), and any run of six or more digits, which is the shape of a one-time code, a phone number, or part of a card number. We do not claim that redaction anticipates every possible form of text, which is why it runs before the record is stored rather than at the moment of sending, and why nothing is sent without your say-so. What you do send is then handled exactly like the problem report above: stored against the installation identifier so the in-app erase (§10) removes it, kept for the period in §8, and read by a person.

3.11 The early-access waitlist

On scanhawk.io/waitlist you can ask to hear when a part of ScanHawk that is not available yet is ready for you. Joining is optional and has nothing to do with using ScanHawk. When you join we keep:

• Your email address and how you are joining — as an individual, for a team, or as a product partner. These two are the only things required.
• Anything else you chose to fill in — first and last name, phone number, company, job title, city, state or region, and country. Leave a field blank and we do not have it.
• Whether you agreed to be called or texted, which version of that wording you were shown, and when you agreed. The box is never ticked for you, and agreeing is not required to join.
• How you found us — the campaign tags in the link that brought you to the waitlist page, if it had any (the utm_ parameters), the address of the page that sent you there as your browser reported it, and the address of the waitlist page itself. Nothing is stored in your browser to work this out; it is read from the page you submit from.
• When you joined, and a status we use to keep track of following up.

We do not keep your IP address with your entry — it is used briefly, in memory, to limit how often the form can be submitted, and otherwise appears only in the ordinary server logs of §3.5. We do not record which device or browser you used, and we do not combine your entry with anything you have checked with ScanHawk. If you join again with the same email address we keep one entry: blank fields are filled from the later visit and nothing you gave before is overwritten.

We use your entry to tell you when the part of ScanHawk you joined for is ready, to offer you a short follow-up call, and to count, without names, how people are finding the waitlist. That is all. We do not sell or share it, and joining does not put you on a newsletter.

We call or text only if you ticked the box, and only the number you gave. We do not currently send text messages; if we start, the commitments in §3.4 apply — the messaging provider is named in §7 before the first message, standard message and data rates may apply, and replying STOP ends them. You can withdraw that consent, or ask us to delete your entry, at any time (§10).

3.12 Subscriptions — ScanHawk Pro

ScanHawk Pro is bought through Apple’s App Store. It is not yet sold on Google Play; on Android, Pro is available only through an organisation’s access code. The store takes the payment. We never receive your card number, billing address, or store account details, and we cannot see them. Refunds and cancellations are handled by the store under its rules.

To confirm a purchase, the app sends us the signed transaction record the store issued for it. We verify the store’s signature on our own servers and keep four things: which product you bought, when the subscription expires, which store it came from, and the store’s opaque transaction identifier. That identifier is how the same purchase finds its way back to you after you reinstall, restore, or lose the secret in §3.2; it is not linked by us to your store account, and we cannot look you up from it. We use no third-party subscription service. We ask the store about your subscription only when the app asks us to — on launch, after a purchase, or when you tap Restore — and the store does not report to us about you on its own.

3.13 Deep Check

A Deep Check, part of Pro, is a second and more thorough analysis of a link you have already checked. Two things happen that do not happen in a standard check.

First, our server may visit the destination page itself. It fetches the page the way a stranger’s browser would — with none of your cookies, logins, or history, so it sees only what anyone on the internet would see — reads at most the first 256 KB, follows no further redirects, runs nothing on the page, and gives up after eight seconds. The page is examined for the shapes phishing takes (a login form on the wrong domain, a brand name the domain does not match, a hidden onward jump) and is then discarded. We do not store fetched pages, and we never fetch a page for a standard check.

Second, an excerpt of that page’s text, alongside the URL, goes to Anthropic for the reasoning step described in §7, under the same terms: not used to train their models. The page text is handled throughout as untrusted data — something to be analysed, never something to be obeyed.

Deep Check results are not cached, and each Deep Check counts against a daily allowance per installation using the counter in §3.5.

4. What the app accesses on your device

Camera. ScanHawk uses your camera for one purpose: to read QR codes. The camera image is decoded on your device — the image itself is never transmitted or stored. Only the decoded text leaves your device.

Local storage. Your installation identifier, a copy of your consent record, your subscription status, and your recent scan history are stored on your device. Scan history stays on the device; we do not upload it. The installation secret (§3.2) is stored in the device keychain rather than ordinary app storage.

Notifications. The app asks for permission to show notifications only when it first has something to tell you, never at launch. If you scanned a code while offline, the app notifies you when the result arrives; that notification is created on your device and involves no server. The app uses no remote push service and registers no push token.

We request no other device permissions — no location, no contacts, no photo library, no microphone.

5. The extension, add-in, and web app

Browser extension. Only web addresses (URLs) leave your browser — never page content, form data, or what you type. By default the extension checks a link only when you ask it to: from the right-click menu, or from the toolbar popup (an address you type, paste or select). Three optional settings are off unless you, or an organisation that manages your browser (§14), turn them on. Scan links when you click them sends the address of a link you click, before it opens. Pre-scanning sends the addresses of the links on the pages you visit, so they can be marked in advance. The hover Scan button shows a small shield after you rest the pointer on a link; it is a shortcut, and nothing is checked until you click it.

QR codes in the extension. When you choose “Scan QR code” or “Scan QR codes on screen”, the extension takes one picture of the visible part of that tab, reads the code inside your browser, and discards the picture. The picture never leaves your browser. Only a web address found in the code is sent to be checked. A code that holds anything else, such as an authenticator setup code, a Wi‑Fi password or a phone number, is not sent, and its contents are not shown or kept.

Verdicts are kept in the browser’s session storage, which is cleared when the browser closes. Your settings and the install token (§3.2) are kept in the browser’s extension storage; if you use your browser’s sync, the browser copies them to your other signed-in devices.

Outlook add-in. The add-in reads the open message inside your mail client and extracts link pairs — the destination (href) and the visible text the link displays. Only those pairs and a context label are transmitted to us. The message body, subject, sender, recipients, and attachments are not sent to our servers. We need the visible display text because the mismatch between what a link says and where it goes is one of the strongest phishing signals there is — which does mean that fragment of the message’s text reaches us.

Installable web app. The PWA behaves like the mobile app and stores the same items in your browser’s local storage.

6. Why we process it (legal bases)

For people in the UK, the EEA, and other regions with equivalent law, our legal bases under the GDPR are:

• Contract (Art. 6(1)(b)) — processing the text you submit in order to return a verdict, which is the service you asked for; verifying and remembering a subscription you bought (§3.12).
• Legitimate interests (Art. 6(1)(f)) — securing the service, preventing abuse, applying rate limits, maintaining the threat feed, improving detection, answering the messages you send us (§3.9), and measuring in aggregate how our website is used so we can tell whether anyone is finding it (§3.5, §3.8). We balance these against your rights and use the least identifying data that works, which is why the installation identifier is random rather than device-derived.
• Legal obligation (Art. 6(1)(c)) — retaining the consent record as evidence of the agreement between us, and responding to lawful requests.
• Consent (Art. 6(1)(a)) — the optional contact details you give us on our website (§3.4) and what you submit when you join the waitlist (§3.11), including any agreement to be called or texted, and only those. You may withdraw it at any time without affecting your use of ScanHawk.

7. Who we share it with

To produce a verdict, the URL being checked may be shared with:

• Anthropic (Claude) — to reason about the destination and explain the risk in plain language. For a verdict we send the URL and page metadata, not information about you; for a Deep Check (§3.13) we also send an excerpt of the destination page’s text, which is handled as untrusted data throughout. If you email us (§3.9), we may also send the subject and text of your message, with your email address removed, so the assistant can help sort it and draft a reply for a person to review. We use Claude through Anthropic’s API, which Anthropic provides under its Commercial Terms; those terms prohibit Anthropic from training its models on what is sent to it.
• Threat-intelligence providers — Google Cloud Web Risk, PhishTank, and URLhaus (operated by abuse.ch in Switzerland) — to return safety signals about the URL.

For verdicts, these providers receive only the URL and, where relevant, its resolved destination. They do not receive your installation identifier or your email address.

We also use infrastructure providers who process data on our instructions under written agreements: Supabase (database and edge functions, including the details you give us on our website, §3.4 and §3.11), Fly.io (engine and worker hosting), Google Workspace (our company email, which holds any message you send us), Postmark (the product-news email you asked for on our website, §3.4, if you gave us an address there, and the delivery to us of any problem report you send from the app, §3.10), Amazon Web Services (storage for the server logs described in §3.5, in a bucket we control in the United States), and Expo (650 Industries, Inc., which hosts the app software updates described in §3.7). Expo receives no URL you checked and no verdict — only what is needed to serve the right update, as set out in §3.7. AWS receives server logs only — no scanned content, no verdict, and no contact details.

We may disclose data where required by law or where necessary to protect the rights, safety, or property of users or the public. If TwentyPin is involved in a merger, acquisition, or sale of assets, data may transfer as part of it; we will give notice before your data becomes subject to a different privacy policy.

8. How long we keep it

• Cached verdicts — expire automatically, typically within 24 hours.
• Check logs — retained no longer than 90 days, then deleted or anonymised.
• Consent records — retained while your installation is active and for up to six years afterwards, because their whole purpose is to evidence an agreement for as long as a claim about it could be brought.
• Installation and subscription record (§3.2, §3.12) — retained until you erase it in the app. A lapsed subscription is kept only so a renewal can find it.
• Deep Check page fetches — not stored at all; discarded once analysed.
• Optional contact details (email address, phone number, the topics you ticked, and any note) — until you unsubscribe or ask us to delete them, plus a suppression entry so we do not contact you again by mistake.
• Waitlist entries (§3.11) — until you ask us to delete them, and no longer than 24 months after you first join; after that the entry is deleted automatically and nothing of it is kept. Withdrawing consent to calls or texts takes effect for the entry straight away.
• Threat feed indicators — retained indefinitely as security data. They describe destinations, not people, and are not linked to you.
• Messages you send us (§3.9) — kept in our company mailbox for as long as needed to deal with them and to keep a record of what was said; the assistant's working record of a message is deleted after 90 days.
• Problem reports from the app (§3.10) — up to 12 months; any email address you included is removed after 90 days whether or not we replied. Erased sooner if you use the in-app erase.
• Server access logs (§3.5) — retained up to 30 days, then deleted automatically by the storage itself rather than on request.

9. What we do not do

• No accounts, passwords, or logins, and no name required anywhere — the only place we ask for one is the waitlist (§3.11), where it is optional.
• No payment details. The app store takes the payment and keeps them.
• No advertising, ad networks, or advertising identifiers.
• No third-party analytics or tracking SDKs.
• No selling or renting of personal data, and no “sharing” for cross-context behavioural advertising as those terms are defined under California law.
• No automated decision-making that produces legal or similarly significant effects about you. Verdicts are about links, not about people.

10. Your rights and choices

In the app. Under About → Privacy & data you can view your installation identifier and consent record, and erase everything we hold that is tied to it — identifier, consent record, the installation and subscription record, any email address stored with them, and any problem reports you sent — in one step. Erasing does not cancel a store subscription; that is done with the store, and a still-valid subscription can be restored to a fresh installation. Deleting the app also removes the identifier and the installation secret from your device.

Depending on where you live, you may also have the right to access the personal data we hold about you, correct it, delete it, receive a portable copy, object to or restrict processing, withdraw consent, and — in California — to know what we collect and to opt out of sale or sharing (we do neither). We do not discriminate against you for exercising any of these rights.

To make a request, email privacy@twentypin.com. We will respond within the time the applicable law requires. Because we hold no account or login, we usually cannot connect a request about the app to your data unless you give us your installation identifier — you will find it in the app under About → Privacy & data. It locates your consent record, your installation and subscription record, and any email address stored with it. It cannot locate your check logs: as §3.5 explains, those carry no installation identifier, so there is nothing in them for us to find, return, or erase on request — they age out on the schedule in §8 instead. If you cannot supply the identifier, use the in-app erasure instead, which needs no verification.

On our website. What you gave us through a website form or the waitlist (§3.4, §3.11) is found by the email address on it. Write to us from that address to see it, correct it, withdraw consent to calls or texts, or have it deleted; if you write from a different address, we may ask you to confirm that the one on the entry is yours before we act.

If you are in the UK or the EEA and believe we have handled your data improperly, you may complain to your local supervisory authority, though we would appreciate the chance to put it right first.

11. Security

All traffic between the apps and our servers is encrypted in transit with TLS. Data at rest is encrypted by our hosting providers. Engine credentials are held server-side and never shipped in a client. Access to production data is limited to those who need it. No system is perfectly secure, but if a breach affects your data we will notify you and the relevant authorities as required by law.

To report a security issue, email security@twentypin.com.

12. International transfers

TwentyPin is based in the United States. Our servers, and every processor named in §7 except one, are in the United States; the exception is URLhaus, which abuse.ch operates in Switzerland. If you are in the UK or the EEA, your data is transferred outside your region when you use ScanHawk.

What protects it today: encryption in transit and at rest (§11), and each processor handling it under its agreement with us. We have not yet confirmed that each of those agreements incorporates the European Commission’s Standard Contractual Clauses or the UK Addendum, so this policy does not claim them. When we have confirmed or put them in place for a processor, we will say so here. Questions about a transfer can go to privacy@twentypin.com.

13. Children

ScanHawk is not directed to children under 13 and we do not knowingly collect personal information from them. If you believe a child under 13 has given us personal information, contact privacy@twentypin.com and we will delete it.

14. Enterprise and managed deployments

This section applies only where an organisation has enrolled its people in ScanHawk — a managed browser-extension rollout, an app deployed through mobile device management, a Microsoft 365 tenant deployment, or API access under a written agreement. If you installed ScanHawk yourself from a store, none of this applies to you and the rest of this policy is the whole of it. Nothing in this section changes what we collect from individual users, and nothing here relaxes §9.

14.1 Who is the controller

In every other part of this policy, we are the controller. In an enterprise deployment we are not: the enrolling organisation is the controller and we act as its processor for the data described below, under the written agreement between us. This matters to you as an individual for one practical reason: for tenant-scoped data, requests to access or delete go to your organisation, not to us, and we will refer you to them. We act on your organisation’s documented instructions, and we use tenant-scoped data only to provide the service to that organisation. One use applies to every check, enrolled or not, and is described in §3.5 and §3.6: when a link is judged suspicious or dangerous, the destination may be added to our threat feed and used to improve detection for everyone. What goes into the feed is an indicator about the destination, with no organisation, installation or person attached. If your organisation’s agreement needs a different arrangement, the agreement will say so.

14.2 What becomes attributable to your organisation

An enrolled deployment is configured with an organisation identifier — an API key, an organisation access code for the app, or an install token for the browser extension, pushed or handed out by your administrator. What it makes attributable to the organisation depends on how checks reach us:

• Under your organisation’s own API key. Each check we store carries the organisation and key it came from, the destination the link actually resolved to, the verdict and risk score, the threat category, the context label, and how long the check took.
• Through the app, the browser extension or the Microsoft 365 add-in. These checks travel under ScanHawk’s own service keys (§3.5), so the stored check is not recorded against your organisation. What the organisation identifier makes attributable is deployment and usage: how many installations are enrolled and how much they are used — counts and dates, never the links checked or the verdicts given.

What this does not add: we still do not receive names, email addresses, usernames, device identifiers, or any directory data from your employer, because nothing in the product transmits them. An individual person is not identifiable to us from a check. Your administrator may be able to attribute activity to you by other means available to them — through the device-management system that installed the software, for example — and that is a matter between you and your organisation.

14.3 Settings your administrator can impose

A managed deployment lets an administrator pin four things: where checks are sent, the organisation identifier, the organisation’s name (shown in the app so you can see who manages it), and whether a Dangerous verdict can still be overridden. Where a setting has been pinned, the app or extension says so and you cannot change it.

Two limits are worth stating because they are enforced in the software rather than merely promised. An administrator cannot weaken the protections — the blocked-scheme rules have no override for anyone, and the dangerous-link setting can only ever be made stricter. And an administrator cannot direct checks to an insecure destination; a configuration that tried to would be discarded rather than applied.

14.4 Reports we produce for your organisation

Where an agreement provides for it, we produce reports for the enrolling organisation from the data in §14.2. For the app, the extension and the add-in these describe deployment and usage — how many installations are enrolled and how much they are used. Where checks are made under the organisation’s own API key, they can also describe links and volumes — for example how many dangerous links were encountered, which categories of threat, and which destinations recurred. Reports are produced at the level of the organisation, a site, or a deployment, and we do not produce per-person reporting, because the data we hold does not identify a person.

14.5 Retention in an enterprise deployment

The retention in §8 is unchanged and it is short: the cached body of a result is cleared within 24 hours. Where an agreement provides for reporting, the aggregate figures derived from it are kept for the term of that agreement and deleted within 30 days of its end, or sooner on the organisation’s written instruction. Per-installation counters, which exist to meter usage, are kept for 30 days.

14.6 Sub-processors and transfers

§7 and §12 apply unchanged — an enterprise deployment introduces no additional recipient of your data. Organisations entitled to advance notice of a change of sub-processor will have that in their agreement.

14.7 If your organisation ends the agreement

Tenant-scoped data is deleted within 30 days of termination, other than anything we must keep by law. Confirmed threat-intelligence entries are the one exception, and deliberately so: a malicious destination that has been confirmed stays in the blocklist that protects everyone, and it is a fact about a link, never about a person or an organisation.

15. Changes to this policy

We may update this policy. The version number and date at the top of this page will change with it. If a change materially affects how we handle your data, we will present it in the app and ask you to acknowledge it before you continue — the same mechanism used for a material change to the Terms of Service.

16. Contact

TwentyPin, Inc. — 2750 FM 1463 Road, Suite 150-70, Katy, TX 77494
Privacy: privacy@twentypin.com
Security: security@twentypin.com
Support: support@twentypin.com