How HRS handles your data

Your organization decides what HumanRisk Shield is used for and whose data goes into it. HRS processes that data on your behalf. In data protection terms, your organization is the controller and HRS is the processor, and the Data Processing Addendum sets out both sides' obligations.

What is collected

About people in HRS Learn. Name, work email, role, department, group membership and any other directory attributes your organization chooses to sync. Then what they do in the platform: training assigned and completed, quiz results, practice phishing outcomes, emails they report, policy acknowledgements, security events, and the risk scores and recommendations worked out from all of that.

From practice phishing. Whether each message was delivered, opened, clicked, submitted or reported, with times, plus country and network-level location. Never city-level location, and never anything typed into a practice page.

In HRS Triage. Emails people report can contain the message content and details about its sender and other recipients, including people outside your organization. Triage uses that only to analyze, decide and clean up the reported message. The details, including which outside threat-intelligence services see links and file fingerprints, are in How customer data is handled.

In HRS Exposure. Findings from public sources and licensed breach and infostealer data about your domains and work accounts. Exposure records that a password was exposed, never the password. Findings about executives keep their name and title from your own public pages, never an email address or credential.

Where it is kept

HRS primarily processes customer data in the United States. HRS Learn runs on SiteGround. The simulation engine and HRS Triage run on DigitalOcean with their own managed database. Backups and content assets are stored with Amazon Web Services. Cloudflare provides the edge network. The sub-processor register is the current list; HRS gives 14 days' notice before adding a new sub-processor.

How it is protected

• In transit: TLS 1.2 or higher on every external connection.
• At rest: databases and backups are encrypted. Directory-sync tokens get an extra layer of encryption inside the application.
• Between systems: calls between HRS products are signed, and the organization they concern is taken from the signed request, never from the message body.
• Between customers: every organization is separated at the application and database level. API keys and tokens belong to exactly one organization.
• HRS staff: no standing access to your organization. Support access is granted per organization, for a limited time, with a reason, and is logged on both sides.

The full set of controls is in the Security Addendum.

How long it is kept

While you are a customer, your data stays until you change or remove it. When the contract ends, you have at least 30 days to export it, and HRS then deletes it from active systems within 60 days. Backups age out on their normal cycle. Malicious samples kept for analysis in HRS Triage are held for up to 180 days. Data from a Google Workspace connection is kept only while the connection is in place.

Your people's rights

When someone asks to see or delete their data, the request goes to your organization, which decides. HRS helps and forwards any request it receives directly. Erasing a person anonymizes them in place, so totals and the audit trail stay intact.

Scores and decisions

HRS works out risk scores and recommendations and gives them to your admins, who decide how to use them. HRS makes no automated decisions with legal or similarly significant effects on people, and the terms say a score must not be the only basis for an employment decision.

AI

Some features use a large language model from a provider on the sub-processor list. Customer personal data is never used to train general models. See How HRS uses AI.