Who We Are
Cybereinforce provides browser-native threat enforcement through Cybereinforce Threat Enforcement (CTE). The platform helps organisations block malicious URLs, enforce policies, and generate security events directly at the browser layer.
This Privacy Policy applies to data processed in connection with the CTE platform and related services. Depending on the context, Cybereinforce acts either as a data processor on behalf of enterprise customers or as a data controller for limited account and service administration data.
Data We Process
Cybereinforce is designed to process the minimum data necessary for threat enforcement, security logging, and administrative operation of the platform.
| Data type | Description | Classification |
|---|---|---|
| Admin email | Used for account access, service administration, and security-related communication. | Required |
| Device identifiers | The device name (the computer name set by the organisation, which can include a person's name depending on how the organisation names its devices), an internal device ID, operating system and architecture, and browser and extension version. Used to associate policy enforcement and security events with enrolled endpoints. | Required |
| Network address | The public IP address from which an enrolled device contacts the service, recorded with enrolment and security events. | Required |
| Page addresses checked for threats | To block a malicious page before it loads, the browser extension sends the address (URL) of each top-level page the user navigates to, and its domain, to the Cybereinforce service for a real-time threat check. URL fragments, embedded credentials and the values of token-like query parameters are removed first. Addresses of pages that are checked and allowed are not stored. Pages that are blocked are recorded as blocked URL metadata (below). | Required |
| Public IOC Lookup | The domains and URLs entered in the free IOC Lookup at /community/ioc-lookup (URLs without their query string), the answer given and the time, used to improve our threat intelligence. No IP address is stored: daily limits and statistics use a keyed one-way code of it. If you ask for a result by email (this needs a signed-in Microsoft work account, see Community membership below), we keep your sign-in name, the indicator and the context you wrote about it, and our analysts see that context with your sign-in name. If you report a false positive or send another request, we keep your email address, your message, which emails you agreed to (with the exact wording and time) and when you confirmed your address. Marketing emails are sent only after you separately agreed and confirmed; every email has a one-click unsubscribe link. | Optional |
| Release notes emails | If you subscribe on our Release Notes page, we keep your email address, the wording you agreed to and when you asked and confirmed it, and a one-way code of your IP address at that time. Nothing is sent except the confirmation email until you click its link. After that we email you once per new release with its release notes, from support@cybereinforce.com. Every email has a one-click unsubscribe link, and unsubscribing stops all emails from us to that address. | Optional |
| Community membership (IOC Lookup) | If you sign in to the IOC Lookup with your Microsoft work account and join the community, we keep your sign-in name (your work email address), its domain, your organisation's Microsoft tenant ID, which boxes you ticked (terms, privacy notice, weekly newsletter, optional daily IOC list) with their exact wording and time, a one-way code of your IP address at that time, and when you joined and last signed in. We use it to give you 100 lookups a day and to send the emails you agreed to. If you sign in from an organisation that is a Cybereinforce client, we only check whether you are a client user or administrator to set your daily limit; nothing is stored for that. Signing in never creates a Cybereinforce tenant. You can delete your membership on the IOC Lookup page at any time. | Optional |
| Blocked URL metadata | Domain, URL (minimised as described above), the rule or intelligence source that matched, and timestamp. This is used for threat visibility and audit trails. A domain that looks suspicious may also be queued for threat-analyst review as a domain name only, linked to the organisation and not to a user or device. | Required |
| Security event logs | Structured audit and security events generated by the platform for monitoring, export, and investigation. | Required |
| Tenant configuration | Administrative settings, integration metadata, and platform configuration chosen by the customer. | Required |
| Integration tokens | Scoped credentials used for customer-approved integrations such as Microsoft Sentinel or Defender workflows. | Optional |
| Aggregate platform usage data | High-level, non-identifying service usage metrics used to improve platform operation and reliability. | Anonymised |
Legal Basis for Processing
Contractual necessity
Certain processing is required to provide the contracted service, including account access, policy enforcement, device association, and operational security logging.
Legitimate interests
Security monitoring, audit trails, and threat intelligence handling support the legitimate interest of protecting customer systems, users, and infrastructure.
Legal obligation
In some environments, security log retention and access controls may support regulatory, contractual, or compliance obligations.
Purpose of Processing
- Real-time threat prevention and URL blocking
- Security event monitoring and audit logging
- Policy enforcement and reporting
- Customer-approved SIEM and Defender integrations
- Incident investigation and operational troubleshooting
Data Sharing & Transfers
Cybereinforce does not sell or rent customer data. Data may be shared only where necessary to operate the service, support customer-requested integrations, or comply with law.
Customer-directed integrations
Customers may choose to export their own security events to systems such as Microsoft Sentinel or other SIEM tooling. These exports are initiated and controlled by the customer.
Infrastructure subprocessors
Limited subprocessors may be used for hosting and infrastructure operation under appropriate contractual and technical safeguards.
Isolated email viewing (Phish-secure with CTE)
When a user chooses Phish-secure with CTE in Outlook, the selected email is opened in a temporary remote browser run by our subprocessor Browserbase, Inc., in the region closest to the customer's data region (Frankfurt for EU and UK customers). The session is not recorded or logged, downloads are blocked, and the browser and everything in it are destroyed when the user closes the window, or after 3 minutes at the latest. Cybereinforce does not store the email content; only the fact that an email was opened (mailbox and message reference) is kept in the customer's security log. Every page opened inside that isolated browser is checked by Cybereinforce before it loads, and each check (website address without its query string, and the verdict) is also recorded in that security log.
To judge how new a website is, the service looks up public domain-registration (RDAP/WHOIS) and certificate-transparency records. These lookups are made from Cybereinforce's own servers and contain only the domain name of the website. No user, device or organisation information is sent.
Where transfers outside the EEA apply, Cybereinforce uses appropriate safeguards such as Standard Contractual Clauses where required.
Data Retention
On termination of service, customer data may be deleted or returned according to contractual terms and customer instruction, subject to applicable legal retention requirements.
Security Measures
Encryption in transit and at rest
Data is protected using modern transport encryption and encrypted storage controls appropriate to the service design.
Role-based access
Access to customer data is restricted to authorised personnel with a legitimate operational need.
Auditability
Administrative and security actions are logged to support accountability, incident response, and compliance review.
Incident response
Cybereinforce maintains incident handling processes designed to investigate, contain, and notify affected parties where required.
Your Rights
Where Cybereinforce acts as a processor, requests should usually be directed first to the customer organisation acting as controller. Where Cybereinforce acts as controller, the following rights may apply:
- Right of access
- Right to rectification
- Right to erasure
- Right to restriction of processing
- Right to data portability
- Right to object where processing relies on legitimate interests
Requests can be submitted using the contact details below. Cybereinforce aims to respond within 30 days where applicable.
Cookies & Tracking
Cybereinforce uses only the limited cookies or session mechanisms necessary to operate authenticated areas of the platform and maintain security controls. The public website additionally uses optional analytics and preference cookies, only as described in the Cookie Policy.
| Item | Purpose | Type |
|---|---|---|
| Session cookie | Maintains authenticated admin sessions and secure request flow. | Necessary |
| CSRF protection | Helps prevent forged requests against authenticated platform actions. | Necessary |
| Preference storage | May retain basic display or locale preferences where enabled. | Functional |
Contact & Privacy Requests
For privacy questions, data subject requests, DPA requests, or subprocessor information, contact the Cybereinforce privacy team.