Privacy Policy

Who we are, and which hat we wear

Short answer: for this website we decide what happens to your information. For everything inside Beam, our customer decides and we act on their instructions.

Rainy Day Security LLC is a managed cybersecurity firm registered in Ohio, United States. Which rules apply to a piece of information depends on which of three roles we are in when we hold it.

• Controller — for information collected through rainydaysecurity.com, our contact form, our billing records and our own correspondence. We decide what is collected and why, and this policy is the whole story.
• Processor, and a service provider under California law — for everything handled inside Beam, our security platform. That information belongs to the customer organization it came from. They are the controller; we act on their instructions under a written contract that forbids us from using it for our own purposes.
• Not a Business Associate — we do not process protected health information for anyone. Where a customer is a healthcare practice, Beam switches mailbox reading off rather than handle protected health information without the agreements HIPAA requires (section 16).

This policy therefore speaks to three different readers: someone visiting this website, an administrator at a customer organization, and a person who works at one of our customers and has never dealt with us directly. Where a section applies to only one of them, it says so.

This website

We do not use advertising trackers, cross-site tracking pixels, or third-party analytics on this website. There is no cookie banner because we set no tracking cookies. Our pages do load their typefaces from Google Fonts, which means Google sees the IP address your browser connects from; nothing else about your visit is shared with them.

If you submit the contact form, we receive your name, email address, organization, what you tell us you need — including whether you are reporting an active security incident, which moves your message to the front of the queue — and your message. We use them for one thing: to reply to you. The form stores nothing; it sends us an email and forgets it. That email is delivered through Resend, our email provider. We do not add you to a marketing list, and we do not sell or share it.

The form is also screened for bots, because it is a public form and automated junk finds it. The screening is a decoy field: an input that no person can see or reach, so anything typed into it can only have come from a machine, and that message is dropped. It asks you for nothing, it involves no other company, and it records nothing you wrote — only a note to ourselves that a message was dropped, so that we can tell if it ever gets one wrong. If you are a person filling in the form you will never know it is there.

Because we do not track visitors across sites, there is nothing for a Global Privacy Control or "Do Not Track" signal to switch off. We honour those signals by never having built the thing they exist to stop.

What Beam collects

Short answer: whatever the customer's administrator connects, so we can watch it for signs of attack. Nothing beyond that.

Customers of our managed service connect Beam to the systems they want us to protect — typically Microsoft 365 or Google Workspace. How much Beam reads depends on the service tier the customer buys and on what their administrator chooses to connect. Across the full service that is:

• Sign-in activity — who signed in, when, from which IP address and the approximate location and network it belongs to, on what device, and whether multi-factor authentication was used.
• Email — where email security is part of the service, Beam examines messages as they arrive and keeps a record of each one: sender, recipients, subject, attachment names, authentication results, and the first 500 characters of the message. For a message Beam judges dangerous it also keeps the full text, so the customer can see what was actually sent to them. The address in the "From" line and the text of the message are encrypted in our database. Held in readable form, because the service has to search and group on them: the subject line, the recipients, the reply-to address, the attachment names, the sender's display name, the address the sending server actually used, and the raw result of the sender-authentication checks. When a message is serious enough for one of our operators to investigate, they open a case about it, and the case title repeats the sender's address and the subject line. The alert we raise about that message carries the sender's address and the subject line as well. Beam also keeps the reply chain a message belongs to, so a fraud that builds over several emails can be recognised as one thing rather than as unrelated messages. Where email security also watches outgoing mail, a message one of your own people sent that looks like a compromised account is recorded the same way — the sender, the recipients, and the first 200 characters of the subject. If you ask us to allow or block a sender, we keep your request, including the address or domain you named. And where Beam cannot act on one of your mailboxes — a licence is missing, or an administrator has fenced us out — we record which mailbox that was, so we can tell you rather than quietly failing.
• Configuration and posture — how the tenant is set up: administrator accounts, mailbox and forwarding rules, sharing and access settings, licensing.
• File and sharing activity — records of documents shared outside the organization or accessed unusually, where the customer's licensing makes that visible to us.
• Exposure — whether the organization's own domains, employee addresses or credentials have appeared in criminal breach data, leak sites, or stolen-credential collections.
• Suppliers and internet-facing services — the vendors the organization depends on, and its own public domains and services, so we can warn it when one of them is breached or exposed.
• Incident evidence — if a customer asks us to examine a specific computer after a suspected compromise, the technical evidence collected from it during that investigation. Section 9 covers this in full.
• The people a customer names to us — a customer's administrator tells us who matters, and we hold what they tell us: who should be paged or emailed when something happens, including a mobile number if they give one; the senior people whose accounts are watched more closely, including a personal email address where the customer asks us to watch one; who to call, in what order, during an incident; and who has completed security-awareness training, where we run that for them.

Alongside that we hold the ordinary records of running a business relationship: the names and work contact details of the people at a customer who use Beam, their sign-in records for the Beam console itself, the messages they exchange with our operators, and billing contacts.

Each customer's data is segregated. One customer's operators, devices and findings are never visible to another customer.

Sensitive information

Some of what Beam examines is what California law calls sensitive personal information, and we would rather name it than let you discover it. In the course of protecting a customer, Beam may handle the contents of email messages, sign-in credentials that have turned up in a criminal dump, and — during an incident investigation on a specific computer — whatever happens to be on that computer. It also holds live credentials of two kinds: the secret behind your own multi-factor code for the Beam console, and the access keys a customer's administrator grants us so Beam can read the systems they asked us to watch. Both are encrypted at rest. The access keys are never displayed to anyone once stored. Your own multi-factor secret is displayed once — to you, on your own screen, at the moment you set it up, because that is how the code is enrolled — and never again, to you or to us. Health information is the one category we deliberately keep out: see section 16.

We collect and use that information only to deliver the security service the customer asked for, and for the narrow purposes the law permits a service provider. We do not use it for advertising, and we do not disclose it except as this policy describes. It does feed one kind of inference, and we name it rather than let the sentence above overreach: Beam learns what normal looks like for an account so that abnormal stands out. Section 10 describes exactly what that pattern contains and what it is never used for. Because we use it only for those permitted purposes, there is nothing for a "limit the use of my sensitive personal information" request to restrict — but you may still ask us, and we will explain what we hold.

Stolen data about people who are not our customers

Short answer: to tell a customer their password has been stolen, we have to hold the criminal collection it turned up in — and those collections are mostly about strangers. We keep it to warn people, never to use it, and we delete it on a clock.

This section is for someone who has never heard of us and would reasonably want to know why we hold anything about them at all. Criminals publish stolen data in bulk: collections harvested from computers infected with password-stealing malware, and the victim lists ransomware groups post to pressure the organizations they have attacked. We collect those the way every credential-monitoring service does, because a password cannot be matched to a customer unless it has first been read, and because a customer's very first scan looks backwards through what was published before they hired us.

The consequence is that we hold records about people who are not our customers and never will be. A record from one of these collections is typically an email address, the stolen password itself, and details of the infected computer such as its name and the account signed in on it. Passwords are encrypted in our database, with one exception we would rather name: alongside the encrypted password we keep the first two characters of it in readable form, so that a customer can recognise which of their passwords leaked without us having to reveal the whole thing to them. We hold this data for exactly one reason — to recognise a customer's address or domain when it appears — and we do not use it for anything else. We never contact the people in it, we never market to anyone from it, we never build a profile of anyone from it, we never sell or license it, and we never show one customer another person's record.

A record in this collection is deleted 24 months after we last saw it in circulation. We would rather be exact about that clock than let you assume a kinder one: it runs from the last time the record appeared in criminal data we collected, not from the first time we recorded it. So a collection that criminals keep re-posting keeps resetting its own clock, and a record only ages out once it has stopped being re-published for two years. Records taken from one particular kind of source — credentials scraped from criminal sites on the Tor network — are deleted sooner, at six months, whether or not they ever matched anyone. If a record turns out to belong to one of our customers it becomes that customer's own security evidence and follows the rules in section 12 instead, because they need the history to know which of their leaks are old news and which are new.

If you think you may be in data like this and want to know, or want it removed from our copy, write to privacy@rainydaysecurity.com. You have that right whether or not you have ever dealt with us, and section 14 explains how we handle the request. We will also tell you plainly that deleting our copy does not delete the criminals' copy — if your password is in one of these collections, change it.

What we never do with it

We do not sell personal information for money or for anything else of value, and we do not share it for cross-context behavioural advertising — the two things California's privacy law means by "sell" and "share". We have not done either in the preceding twelve months, including with sensitive personal information, and we have no plans to. That is why you will not find a "Do Not Sell or Share My Personal Information" link on this site: there is no such activity to opt out of.

We use a customer's information to protect that customer, and for nothing else. It is not rented or given to advertisers or data brokers, and it is never handed to an outside AI company to train that company's model.

There is one thing we do build from it, and we would rather name it plainly than let "we don't train on your data" quietly do more work than it should. The detector that decides whether an email is a phishing attempt is a single model shared across our customers, and it learns from the numbers we assign each message — how unusual the sending route was, how the links behaved, how far a display name sits from the address behind it, and whether our operators later marked the verdict right or wrong. What it never receives is the words in a message, its subject line, its attachments, anyone's email address, anyone's name, or the name of the customer it came from. Its output is a risk score. That is what makes the next customer's inbox safer because of something we learned at the last one, and it is the honest limit of it.

The companies listed in section 11 receive information as service providers doing a job for us — under contract where we hold one, and otherwise under their published terms of service — never as independent recipients free to use it for their own purposes.

What crosses between customers

What crosses that line is the machinery of an attack, never a person. Defending several organizations at once is only worth anything if what we learn at one of them arrives at the others before the attacker does. Four things travel, and this is all of them.

Threat indicators. When we confirm that a site, a sending domain, a link or a file is hostile at one customer, the indicator itself — the address of the bad thing, and nothing around it — is added to the catalog every customer is defended with. A sender's own email address is added only in a scrambled form that cannot be read back. One caveat we would rather state than have an auditor find: where the hostile thing is a web address, we record that address in full, including anything after the question mark. Attackers routinely put the intended victim's own email address there, to pre-fill the fake sign-in box — which means a shared indicator can carry the address of the person the attack was aimed at. Removing that before an address is shared is on our list.

Rules our operators write. When an operator writes a rule to catch a particular kind of hostile mail, that rule can be marked as applying to every customer rather than only the one it was written at. What travels is the rule — the pattern to look for and what to do about it — not the message that prompted it.

A sending domain's track record. For each domain that sends mail to any of our customers we keep a running count of how it has behaved: how many messages we have seen from it, how many we judged hostile, when we first and last saw it, and how many customers it has written to. It is a tally against a domain name, not against a person or a mailbox, and it is kept for every domain rather than only bad ones — knowing that a domain has written honestly ten thousand times is exactly what stops us flagging it on the ten-thousand-and-first.

The shape of a mass campaign. When the same attack lands at more than one customer at once, we group it: the sending domains, the link domains, the file fingerprints, the attachment names and file types, the words the subject lines have in common, how many messages, and how many organizations. We store no message, recipient or sender in that group. The shared group itself records only how many organizations were hit, never which ones — but inside each customer's own records we do keep the link between their message and the campaign it belongs to, because that is how we tell that customer they were caught in it.

Two things in that group deserve more honesty than "the words the subject lines have in common". Where a mass campaign sent every one of its messages with an identical subject — which is the ordinary case — the words they have in common are that subject, stored verbatim. And attachment names travel with their words intact, so a campaign that attached a file named after the person it was sent to carries that person's name into the shared group.

What is never shared is who received something, who visited it, or which customer it was seen at. But we will not tell you that none of it could ever identify a person: as the two paragraphs above describe, a hostile web address and an attachment name are both written by the attacker, and an attacker who names a file or a link after their victim puts that name into the shared catalog. What we can tell you is that we do not use it that way, and we do not attempt to work backwards from it to a person.

Beam Browser Defense (the browser extension)

Short answer: it warns the person at the keyboard about scam pages. It does not record where you go, what you type, what you paste, or what is on the page.

Beam Browser Defense is a browser extension we provide to customers on our SHIELD service tier. Its single purpose is to warn the person using the browser when the page in front of them shows a known sign of a security scam — a fake sign-in page, a paste-to-run instruction, a copycat web address, a dangerous download. It only functions after an administrator connects it with a one-time code issued from that organization's own Beam console; before that, it does nothing and sends nothing.

It warns rather than blocks. There is one exception in force today: an administrator can name specific sites their own organization wants stopped outright, and those are stopped before they load. A second, broader mode — where a warning becomes a block everywhere — is built but switched off across the whole service, and an administrator cannot turn it on alone; it takes a change by us as well. And if you heed a warning about a dangerous download, the extension removes the file it warned you about.

The extension also keeps a short record on your own computer, and since a record is a record wherever it sits we would rather name it: the last two hundred warnings it raised — each with the full address of the page it happened on — the last twenty-five site names it warned about, and a thirty-day tally of how often it acted. That is held in the browser's own storage on your device, so the extension can show you your own recent warnings and avoid nagging you twice about the same site. Only what the table below describes is ever sent to us; the rest stays on the machine and goes when the extension is removed.

What it does send

Detection happens entirely inside the browser. The judgment — the list of scam patterns to look for — is compiled by that customer's own Beam tenant and delivered to the extension as data. Almost everything below is sent only when a warning is raised, so that customer's security team can respond. The two exceptions are marked, and neither carries anything from the page — one sends a suspected copycat address to be scored, the other asks about a single site name the local list was unsure about.

One important caveat about that label, and about a second field beside it. The label is free text, chosen by the customer's own administrator, and in practice an administrator can label an enrolled browser with the name of the person who uses it — that is usually the point, since it is how their security team knows whose device raised a warning. Separately, an administrator can attach the work email address of the person a browser belongs to. Neither is required, neither is asked for, and the extension never works out who you are on its own — both come from your employer.

Where an administrator has filled in that email address, it does two things you should know about. It is written into the warnings raised on that device, so those warnings name the person. And it is what lets us line a browser warning up with that same person's sign-in records — which is how we can tell that someone who was warned about a fake sign-in page then had their account signed into from somewhere strange, and is the point of running the two together. That linking happens only inside that customer's own data, and the result is visible only to that customer's administrators and to the Rainy Day Security operators delivering their service.

The extension has exactly one network destination — the Beam service at api.beam.rainydaysecurity.com, operated by us on behalf of that customer. It contains no analytics tools, no advertising code, and no third-party services of any kind. It downloads no code: everything it runs is in the package you installed.

Who sees it

Warnings raised on a customer's devices are visible to that customer's own administrators and to the Rainy Day Security operators delivering their service. No other customer sees them, and they are never sold, rented, or shared with advertisers or data brokers.

The threat-indicator exception described above applies here in one specific way. When people at two or more separate customers are each warned about the same site and each choose to back away from it, that is the strongest evidence a security service can get that the site is genuinely hostile — so the name of that site joins the list of suspect sites every customer's extension checks against. What crosses is the name of the site and nothing else: no person, no device, no customer's identity, and no record that any particular person went there.

Chrome Web Store commitments

The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements. In plain terms: what the extension collects is limited to what its single purpose requires; information about the web pages you visit is used only to raise the warning described above and to let your own security team act on it; and it is never transferred, used or sold for advertising or personalization, never given to data brokers, never used to assess creditworthiness or lending, and never used to train a machine-learning model. Human beings see it only where a Rainy Day Security operator or one of that customer's own administrators is investigating a warning.

Incident investigations

If a customer asks us to examine a specific computer after a suspected compromise, the evidence we collect is technical: running programs, sign-in records, network connections, scheduled tasks, and similar artifacts that show what an attacker did. An investigation is scoped to that question, and we look at what the customer has asked us to look at.

Much of what we deliberately collect is a record of what a person did on that computer, and we would rather name all of it than call any of it incidental. On a machine under investigation we take the last seven days of browser history — up to two hundred addresses across the machine, with the title of each page as well as its address — the commands typed into PowerShell, and the script text and command lines Windows itself recorded for programs that ran. We take a per-user history of which programs were run and when, going back further than the machine's running programs can show. We take a timeline of files created and changed — up to three thousand entries — the last two hundred documents and folders opened from the taskbar or recent-items list, the accounts on the machine, and the record of which files were downloaded from the internet and from where. From each browser profile we also take safety settings and a count of how many passwords are saved in it — the count only, never a password, never a site they belong to. Those are the artifacts that show how an intruder got in and what they touched, and there is no version of that examination that does not see them.

Two parts of that examination ask outside services a question, and we would rather name that than let "we collect evidence" imply nothing leaves. Fingerprints of programs found on the machine — a mathematical fingerprint of the file, never the file and never its contents — are checked against VirusTotal, up to a few hundred per examination. And the addresses the machine had been talking to, taken from its network connections, its address-lookup cache and its hosts file, are checked against the reputation services named in section 11. What is sent is a fingerprint or an address on its own, with no name, no account, no file and nothing about the person using the machine.

Beyond that, evidence taken from a working computer can also incidentally include personal material — a file name, an email address belonging to someone who is not the subject of the investigation. We treat all of it as the customer's confidential information, restrict it to the people working the investigation, and do not use it for any other purpose. It is held with that customer's other findings and destroyed on the schedule in section 12, unless the customer instructs us to preserve it for a legal hold.

Automated analysis and AI

Beam is automated by design — that is how a small firm can watch a lot of systems. Most of our detection is deterministic: fixed rules and lists, written in advance and reviewable. Two things are not, and we would rather say so. Part of an email's risk score comes from a trained model — a pattern learned from mail we have judged before, not a rule a person wrote — and every verdict records which version of that model produced it, so any decision can be explained afterwards. And where we use a language model, it is to turn technical findings into the plain-English briefings customers read.

Those models run on Amazon Bedrock, called from our own Amazon Web Services account. Customer data does not go to a model vendor's own service, and no model vendor trains on it. A briefing is drafted by a language model from that customer's own findings, checked automatically for length and formatting — and replaced with a plainer summary we wrote in advance if the model fails to produce one — and then delivered on the schedule that customer's service tier sets. Where a document has to cite specific findings, we check every citation against the findings we actually gave it and reject any the model invented; ordinary briefings get the length and formatting checks, not that one. Our operators supervise that queue and can hold or withdraw anything in it — but we are not going to tell you a human being reads every word of every briefing, because on the ordinary schedule one does not.

We do not use automated processing to make decisions about individuals that would have a legal or similarly significant effect on them — nothing here feeds an employment, credit, insurance or housing decision. Where an automated action is taken, it is taken against an account or a message rather than as a judgment about a person: quarantining a dangerous message, reversing a mailbox rule an attacker created, signing a compromised account out of everywhere it is signed in, or forcing a password reset. Some of those are disruptive to the person whose account it is, and we would rather say so than describe them all as acting on "a system". None of them happens unless a customer has connected their systems to us and authorized automated remediation, and each kind of action then has its own separate setting, and every one of them is logged. One correction to a sentence this page used to carry: it is not true that every kind of action starts switched off. Once a customer has authorized automated remediation, one action is set to act on its own out of the box — removing a mailbox forwarding rule that quietly sends someone's mail to an outsider, because that is the single most common thing an attacker sets up and leaving it in place while we wait costs the customer the mail. Every other kind waits to be turned on, and any of them, including that one, can be turned off. Where the trained model rather than a fixed rule is what raised the alarm, the action is normally held back for one of our operators to look at first; if nobody has looked within a day it proceeds, and the record says that is what happened. For a customer whose mail we have tuned over a long period we can lift that hold, and we tell that customer when we do.

There is one thing we should be plain about, because "we don't profile people" would be too easy to say and not quite true. Detecting a stolen account means noticing that an account is behaving unlike itself, so Beam learns each person's ordinary pattern — the networks and browsers they normally sign in from, the hours they normally work, each mailbox's ordinary sending pattern (the people it usually writes to, the hours it usually sends, the sort of thing it usually sends about), which people at a supplier normally write to the customer, and who normally writes to whom inside the organization. That pattern exists for one purpose: to make a sign-in from an unfamiliar place, or an invoice request from a correspondent who has never sent one, stand out. It is never used to judge, rate or report on a person's work, it is never combined across customers, and it is never shared. The pattern of who writes to whom is dropped 180 days after a correspondent goes quiet, the mailbox and supplier patterns are dropped after 90 days without an update, and the sign-in pattern goes when the customer's data does.

Who we rely on

A small number of providers help us run the service. They process data on our instructions and are bound by contract; none of them is permitted to use it for their own purposes. We name them rather than saying "a list is available on request", because a customer's auditor should not have to ask.

• Amazon Web Services — hosting, storage and databases, in United States regions. The language models that draft our plain-English briefings run on Amazon Bedrock, called from our own AWS account, so customer data does not go to a model vendor's own service and is not used to train anyone's model.
• Cloudflare — this website.
• Resend — outbound email.
• Stripe — card payments. Stripe receives billing contact and payment details directly; we never hold full card numbers.
• Pushover and Microsoft Teams — how our own on-call staff are told when something needs a person. Two different things travel here. A page — the thing that wakes someone at night — names the customer it concerns and the condition that raised it; and where the condition is about a person, it names them too: the account involved, the IP address it was seen from, and any note the person who asked for help typed to us. It has to, or the person woken up cannot act on it. Our internal Teams channel additionally receives the ordinary running commentary of the service, and where a person at a customer has asked us for help, or asked to see one of their own exposed credentials, that notice carries their name, their work email address and any note they typed to us, because that is what our staff need in order to answer them. Neither carries the contents of an email, the contents of a web page, or anything you typed anywhere other than to us.
• Security intelligence services — to decide whether something is dangerous, Beam asks outside reputation services about one specific indicator at a time: a web address or attachment found in a customer's email, an IP address someone signed in from, an employee's email address being checked against breach corpora, or a domain name being checked for impostors. Only that indicator is sent, never the message or the page it came from. Two of them see an IP address a real person signed in from: ip-api.com, to turn it into a city, and AbuseIPDB, to say whether that address is known for attacks. XposedOrNot and LeakCheck receive an employee's email address, or a customer's own domain, to check against breach and stolen-credential collections. crt.sh and RDAP receive a customer's own domain name so we can find domains registered to impersonate it, and urlscan.io receives a customer's own brand and domain for the same purpose. RDAP is also asked, one at a time, for the date an ordinary website's domain was registered — a long-standing domain is one of the ways Beam recognises a legitimate site and avoids warning someone away from it. That is a public fact about the website, not about the person who visited it, and we do not tell RDAP who visited anything. abuse.ch (ThreatFox, URLhaus and MalwareBazaar) receives a web address, an IP address or a file fingerprint, to say whether it is already known malware infrastructure. GreyNoise, Shodan and ThreatMiner are asked only about indicators already sitting in our own catalog of known-bad things — never about a customer's people, and never about a sign-in. And where a customer enables them, Google Safe Browsing, VirusTotal and Hybrid Analysis receive a web address or a file fingerprint. Four of these are operated outside the United States — LeakCheck, XposedOrNot, urlscan.io and abuse.ch — and section 18 says what that means.
• Google Fonts — the typefaces on this website, in the customer console at beam.rainydaysecurity.com, and in the reports we generate for customers. Google sees the IP address of the browser that loads them, and nothing else — not who you are, not what you were looking at, and no cookie.
• jsDelivr — our Outlook add-in loads Microsoft's sign-in library from this public code distribution network, which is operated internationally. jsDelivr sees the IP address of the browser that loads it, and nothing else. The file is checked against a fingerprint we pinned in advance, so a tampered copy will not run. Replacing it with a copy served from our own systems is on our list.

We do not sell personal information to anyone, for any price.

If we add a provider that receives customer information, we update this section. Where a customer's contract requires advance notice of a new subprocessor, we give it.

How long we keep things

Short answer: findings last as long as the customer relationship; the raw activity behind them is pruned automatically, most of it inside 90 days.

Two honest caveats. Deletion from our live systems is automatic and on the schedule above; encrypted backups age out on their own cycle shortly afterwards. And if a customer places a legal hold, or the law requires us to preserve something, we keep that item until the hold lifts and delete it then.

These windows are pinned to the code that enforces them. Our own build fails if a retention setting in Beam stops matching what this page says, so a promise here cannot quietly drift away from what the software does.

How we protect it

Data is encrypted in transit and at rest. Particularly sensitive fields — the sender and the contents of an email, a message to your security team, a stolen password we are holding, the access keys a customer grants us, the secret behind a multi-factor code — are encrypted a second time at the level of the individual field, so they are unreadable even to someone holding the database. Not everything is, and this is the full list of what is not: a message's subject line, its recipient list, its reply-to address, its attachment names, the sender's display name and the raw sender-authentication result; the record of who inside an organization corresponds with whom; what you type to the Beam assistant inside your own console; the notes our operators write about your organization; and — the one we would least like you to find on your own — the note you type when you ask us for help. That last one is not only readable in our database, it is also sent onward to the internal channel that alerts our on-call staff, which is the whole point of typing it. Closing these gaps is on our list; the message you send an operator through the console is already encrypted, and the help-request note should be too.

Three exceptions to "encrypted in transit" we would rather name than have you find. To tell you what city a sign-in came from, Beam asks the geolocation service named in section 11 about that IP address, and that one service's free interface is not encrypted — so a bare IP address, with no name, no account and no company attached, travels unencrypted on that single lookup. When we test a customer's own internet-facing systems at their request, we deliberately try them over an unencrypted connection, because finding out whether that works is the point of the test. And when we open a link found in a customer's email to see where it leads, we follow it as written, which sometimes means an unencrypted address. Nothing else we send anywhere is unencrypted, and the geolocation one is on our list to close.

Each customer's data is separated inside our systems, and every request for it is scoped to a single customer. To be precise about how: that separation is enforced by the application rather than by the database itself, and it is tested, but we will not claim a second lock we have not fitted. Access is limited to Rainy Day Security staff delivering the service, and we do not today restrict an individual member of our staff to a subset of customers. Multi-factor authentication is mandatory for Rainy Day Security staff accounts, and available to every person at a customer; whether it is required of a customer's own people is that customer's decision, and we report to them on who has not turned it on. Administrative access is logged, and that log is never deleted. Our own infrastructure is scanned for known-exploited vulnerabilities using the same intelligence we sell, our code is reviewed by automated security analysis before it ships, and we are writing our own information security plan against the NIST Cybersecurity Framework — the same discipline we build for our customers, and honestly described: it is a working draft with known gaps, not a finished programme.

No method of transmission or storage is perfectly secure, and we will not tell you otherwise. What we will tell you is what we do, and what happened if something ever goes wrong.

Your privacy rights

Short answer: email privacy@rainydaysecurity.com. We answer within 45 days, and we will not treat you worse for asking.

You may ask us to:

• Tell you what we hold — the categories of information about you, where it came from, why we have it, and who we disclosed it to.
• Give you a copy of the specific pieces of information we hold about you, in a portable form.
• Correct anything that is wrong.
• Delete it, unless we are required to keep it.
• Opt out of sale, sharing, or targeted advertising — which needs no action, because we do none of those things.

Write to privacy@rainydaysecurity.com or use the contact form. We acknowledge a request within 10 business days and answer within 45 days; if a request is genuinely complex we may take one further 45 days, and we will tell you why before we do. We will ask you for enough information to be confident you are who you say you are — we are not going to hand your records to someone who merely knows your email address. An authorized agent may act for you if they give us written proof you asked them to.

We will not discriminate against you for exercising any of these rights. Nothing about the service you receive changes because you asked a question about your privacy.

If we deny a request, we will explain why, and — where your state's law provides for it — you may appeal that decision by replying to us. We will decide an appeal within 45 days, and if we still say no we will tell you how to raise it with your state's attorney general. California residents may also ask, once a year, about disclosures to third parties for their direct marketing purposes under the "Shine the Light" law; the answer is that we make none.

If you work for one of our customers

Most of the personal information we handle belongs to organizations we work for, not to us. If you are an employee of one of our customers and you want to see, correct or delete information held in their Beam tenant, the decision is theirs to make: they are the controller and we act on their instructions.

So write to your own organization first. If you write to us instead, we will forward your request to them, tell you that we have, and help them answer it within the time their contract with us requires. What we will not do is act unilaterally inside a customer's tenant on the instruction of someone who is not the customer — deleting security records at an individual's request is exactly the move an attacker would ask us to make.

Health information

Short answer: we do not take on protected health information. If you are a medical practice, the part of Beam that would read your mail is switched off, and we would rather tell you that than take it on without the paperwork HIPAA demands.

HIPAA lets a security company handle protected health information only as a Business Associate, under a signed Business Associate Agreement, with the same agreement in place with every supplier who could touch it, and a formal Security Rule programme behind it. Rainy Day Security does not have that today. So rather than run the parts of Beam that could see protected health information and hope none arrives, we turn them off.

For any organization we have identified as handling protected health information — because an operator marked it, or because of what it does — Beam refuses to connect to its Microsoft or Google tenant at all. The connection will not complete, and email content is never read or scanned. The refusal is at the connection, not at the mailbox, so the other things that connection would have fed do not run either: sign-in monitoring and the parts of security posture that read the tenant are off for those organizations. What continues normally is dark-web and stolen-credential monitoring, supplier and internet-exposure monitoring, briefings and reporting — and, because it is our own front door rather than their tenant, the record of sign-ins to the Beam console itself, including the city each one came from. This is enforced in the software rather than promised in a policy, and our own build fails if that stops being true.

We also do not sell our top service tier into those organizations, because most of what it is worth depends on the connection we have just refused. That one is a commitment we keep by hand at the point of sale, not something the software enforces — and we would rather say which is which than let one sentence borrow the other's credibility.

We are therefore not a Business Associate of anyone, and we do not sign Business Associate Agreements today. If that changes — the agreements signed, the supplier chain covered, the programme in place — this section will change with it, and it will say what we then do. Until it does, treat any claim to the contrary as wrong.

If some health information nonetheless reaches us — a customer sends it to us in a message, or it turns up incidentally in evidence from an investigation — we treat it as that customer's confidential information, restrict it to the people working the matter, never sell it, never use it for marketing, and delete it on the schedule in section 12. And if we ever learn we are holding health information we should not be, we tell the customer promptly so they can meet their own obligations.

Your rights over your own medical records run against the practice that treats you. Their Notice of Privacy Practices — not this page — is the document that describes them.

Government and law-enforcement requests

We have never received a national security order or a demand for a customer's data, and if we do, our posture is this: we require valid legal process, we push back on anything overbroad, and we produce the narrowest thing the law obliges us to produce.

Where the data belongs to a customer, we would rather the request went to them, and we will say so. If we are served directly, we will tell the affected customer promptly so they can respond themselves, unless we are legally forbidden from telling them — in which case we will tell them as soon as that restriction lifts.

Where your data is held

Everything we hold is stored and processed in the United States, in Amazon Web Services regions inside the United States. We do not move a customer's records to systems outside the country. Three honest qualifications, because "nothing leaves the country" would otherwise be doing more work than it can carry.

First, our websites and consoles are delivered through a content network whose edge locations include Europe, so a request you make may be served from outside the United States even though the data behind it never leaves.

Second, and this is the one that matters: some of the outside services in section 11 that we ask single questions of are operated abroad, and a question can contain a person's work email address or a customer's domain name. XposedOrNot is operated from India and LeakCheck from Cyprus, and both receive an employee's email address when we check whether it has been caught in a breach. urlscan.io is operated from Germany and abuse.ch from Switzerland, and both receive addresses and domains rather than people. In every case what travels is the single thing being asked about, never a record, a message or a file.

Third, the code network our Outlook add-in loads a Microsoft library from is operated internationally, and sees the IP address of the browser that loads it.

We sell only to organizations in the United States and this service is not offered to residents of the European Economic Area or the United Kingdom. If a customer's own systems happen to contain records about employees who live there, that customer is the controller of those records, and we will sign a Data Processing Agreement with the appropriate transfer terms on request.

If something goes wrong

If personal information we hold is breached, we will say so. For a customer's information we notify that customer without unreasonable delay, on the timetable their contract sets, with what we know and what we are doing about it — and we keep updating them as we learn more rather than waiting for a tidy final answer. Where Ohio law or another state's breach-notification law requires us to notify affected individuals directly, we do that too, within the time the law allows.

If our business changes

If Rainy Day Security is ever sold, merged, or reorganized, information we hold may transfer to the successor as part of that transaction — bound by this policy, or by one at least as protective, until it is properly replaced. Customers would be told before it happened, not after. We will not use a corporate transaction as a back door to selling data we have promised not to sell.

Children

Our services are sold to organizations and are not directed at children. We do not knowingly collect information from anyone under 16, and if we discover that we have, we delete it.

Changes to this policy

If we change what we collect, we will change this page and move the "last updated" date at the top. Material changes affecting customers are also communicated directly, before they take effect. We will not ask you to check back periodically to find out whether we have changed our minds.