BnR360 Security and Trust Statement
Effective Date: 6 October 2026.
1. Nature of this Statement
1.1 This Statement describes BnR360's security approach for Sphere, NeuroHire, GenRapide, GenRapide Light, NexGen RFP and related infrastructure. It is informational. It is not a certification, an audit report, a warranty, or a guarantee that a security incident cannot occur. Binding security commitments are those in the Master Subscription Agreement, the Data Processing Addendum (including Schedule 2), and any Order Form or Security Schedule signed by BnR360.
2. Certifications
2.1 BnR360 does not currently hold ISO/IEC 27001, SOC 2, FedRAMP, PCI DSS, CSA STAR or similar independent certifications, and does not claim to. Microsoft Azure and DigitalOcean maintain their own certifications and attestations for their infrastructure. Those belong to the providers and do not make BnR360 certified. In sales material and questionnaires BnR360 must say: “BnR360 uses infrastructure providers that maintain their own security certifications and attestations. BnR360's own certifications, where applicable, are identified separately.”
3. Governance and Shared Responsibility
3.1 BnR360 seeks to maintain documented practices for access management, infrastructure security, secure development, vulnerability management, incident response, data protection, vendor management, backups, continuity and AI related security, with responsibilities assigned among management, development, operations and privacy personnel or service providers.
3.2 Security is shared. BnR360 is responsible for controls on the platform and infrastructure under its control. Customers are responsible for user administration, role assignment, passwords, endpoint security, exported data, Customer controlled integrations and credentials (including any bring your own API key or tenant), and lawful configuration of the Services.
4. Hosting and Data Location
4.1 BnR360 hosts the Services on Microsoft Azure and DigitalOcean. The provider and region may vary by product, environment and Customer configuration. BnR360 does not promise that Customer Data is stored in one country or region. A residency requirement applies only if recorded in the Order Form, Security Schedule or DPA.
4.2 BnR360 seeks to keep production, development and test environments separate and not to copy production Customer Data into lower security environments without need. Production Personal Data should not be used for testing unless necessary, and then with restricted access.
5. Access Control and Authentication
5.1 Production access is limited to personnel who need it for operations, support, security or maintenance, on a least privilege basis, with stricter control of privileged accounts. Access is adjusted or revoked when personnel leave or change role. Personnel with system access are bound by confidentiality obligations and receive security awareness guidance.
5.2 Products support role based access. Customers assign roles and are responsible for periodic review and prompt removal of former users.
5.3 Authentication uses secure session management and tokens. Passwords are not stored in plain text. Multi-factor authentication is not enabled by default and is available on request for all Products. Customers must protect credentials and report suspected compromise promptly.
6. Encryption
6.1 BnR360 protects data in transit using HTTPS (TLS) and encrypts data at rest. Algorithms and key management details are confirmed on request and before they are made a contractual commitment.
6.2 Encryption reduces risk but does not remove risks from credential theft, endpoint compromise, misuse by authorised users or application vulnerabilities.
7. Secure Development and Vulnerability Management
7.1 BnR360 seeks to build security into development through access restricted source code, peer review, dependency review and updates, secure configuration, secrets management (credentials are not intentionally stored in code repositories), testing and remediation.
7.2 BnR360 seeks to identify and remediate material vulnerabilities using dependency scanning, infrastructure and configuration review, code review and vendor alerts, prioritised by severity, exploitability, data exposure and customer impact, with expedited treatment of critical issues. BnR360 may conduct or commission penetration testing but does not commit to a schedule unless one is stated in an Order Form.
7.3 Customers must not conduct penetration testing, vulnerability scanning, attack simulation or automated security testing against BnR360 systems without BnR360's prior written authorisation.
8. Logging, Monitoring and Audit Trails
8.1 BnR360 may keep logs of authentication, administrative activity, security events, system events and errors to support investigation, troubleshooting, fraud detection and monitoring. Monitoring cannot detect every threat, and malware controls and file scanning do not guarantee detection of every malicious file.
8.2 Certain products provide Customer visible audit history. NexGen RFP aims to keep records of material actions such as criteria changes, scoring and formula changes, evaluator actions, approvals and timestamps. NeuroHire aims to keep records of assessment version, completion, scoring event, AI assisted result, human review and final Customer action. Scope depends on product and subscription.
8.3 Limited AI related records (request identifiers, product, feature, AI Provider, timestamp, operational metadata) may be kept for troubleshooting, security, compliance and performance monitoring, and any Personal Data in them is governed by the Privacy Policy and DPA.
9. Backups, Continuity and Recovery
9.1 BnR360 takes weekly backups of Customer Data, protected by access restriction and provider safeguards, and maintains reasonable recovery processes. Backup practices vary by product and data type. Deleted data may remain in backups until normal rotation completes, and is not restored or provided after the Export Period, which ends 30 days after the subscription ends.
9.2 BnR360 does not guarantee zero downtime, zero data loss, or immediate recovery. Availability, recovery time and recovery point commitments apply only where set out in an agreed service level schedule.
9.3 BnR360 may carry out scheduled or emergency maintenance and security changes, with notice of material planned maintenance where practicable, and may make immediate changes to remediate a vulnerability, block an attack, protect Customer Data or comply with law.
10. Incident Response
10.1 BnR360 seeks to maintain an incident response process covering identification, triage, containment, investigation, remediation, recovery and notification where required, escalated by severity, affected data and customer impact.
10.2 Where the DPA or Applicable Law requires, BnR360 will notify an affected Customer without undue delay after becoming aware of a confirmed Security Incident involving Customer Personal Data, in the time and manner stated in the DPA. Information may be provided in stages as the investigation proceeds.
10.3 BnR360 may cooperate with law enforcement, regulators and courts where legally required and, where lawful, may seek to narrow overbroad requests.
10.4 Customers must promptly tell BnR360 of compromised credentials, unauthorised users, stolen API keys or suspicious activity.
11. Vendors, Subprocessors and Third Party Failure
11.1 BnR360 relies on Microsoft Azure and DigitalOcean for infrastructure and on OpenAI, Google (Gemini) and DeepSeek for AI functionality, together with other providers. The detailed Subprocessor list is available on request in the Subprocessor Disclosure. Where a provider processes Customer Personal Data for BnR360, BnR360 seeks to bind it by contract in line with the DPA. BnR360 may assess providers on security posture, privacy practices, contractual safeguards, availability, data location and regulatory requirements.
11.2 BnR360 does not control the security environment of independent providers. Subject to clause 14 of the MSA and to Applicable Law that cannot be excluded, BnR360 is not responsible for any security incident, outage, vulnerability, failure, AI output or unlawful act of a Subprocessor or other third party provider, and does not guarantee that any such provider will not suffer one. Mandatory obligations under Applicable Law and the DPA are unaffected.
12. AI Security
12.1 AI introduces risks beyond ordinary software, including prompt injection, malicious documents, unintended disclosure, inaccurate output, model manipulation, unauthorised AI use and compromise of an AI Provider. BnR360 may apply technical and organisational measures to reduce these risks, but no current architecture can prevent all adversarial prompting.
12.2 BnR360 designs AI enabled workflows so that one Customer's data is not intentionally exposed to another Customer through the AI Features. Certain AI Features send relevant data to AI Providers as needed to perform the requested function, as described in the AI Addendum and DPA.
12.3 BnR360 does not intentionally use identifiable Customer Data to train a general purpose model for unrelated customers. Provider side training and retention depend on the service, endpoint, contract and configuration, and BnR360 makes no blanket representation of identical settings across providers. BnR360 does not represent that every AI Feature runs on zero data retention. Any such commitment must be recorded in an Order Form or AI schedule.
12.4 Where a Customer selects or connects its own AI provider, key or tenant, the Customer is responsible for assessing that provider and securing the credentials.
13. Data Handling Limits
13.1 Customers should upload only what a workflow reasonably needs and should not upload passwords, payment credentials, unrelated health records or unnecessary government identifiers.
13.2 Classified information. Unless BnR360 confirms an authorised environment in writing, Customers must not process classified, national security or restricted government information in the Services. Use of Sphere to track personnel clearance status does not mean BnR360 holds any facility clearance or accreditation.
13.3 Government and public sector Customers who need specific residency, encryption, audit, retention, personnel or government cloud requirements must have them recorded in an Order Form or Security Schedule.
13.4 After a Customer exports data, the Customer is responsible for the security of the exported copy. BnR360 cannot secure Customer controlled devices, browsers, networks or email accounts. BnR360 staff will not ask users to disclose passwords by ordinary email.
14. API Security and Abuse Controls
14.1 Where APIs are available, access may be protected by tokens, keys, access controls and rate limits. BnR360 may rate limit to prevent abuse and protect availability. Cloud controls may reduce denial of service risk, but BnR360 cannot guarantee immunity from large scale attacks.
14.2 BnR360 may suspend an account where reasonably necessary because of suspected compromise, fraud, malicious activity, serious security risk or a material breach of the Acceptable Use Policy.
15. Reviews, Questionnaires and Vulnerability Reports
15.1 Enterprise Customers may request a security review or send a questionnaire. BnR360 will answer from its actual architecture, controls, vendors and practices, and may withhold secrets, keys, exploit details and defensive configuration that would weaken security. Sensitive detail may be shared only under confidentiality.
15.2 To report a suspected vulnerability, email support@bnr360.com with the subject “Security Vulnerability Report”. Reporters must not access more Customer Data than is needed to demonstrate the issue, destroy data, disrupt production, or publicly disclose the issue before BnR360 has had a reasonable opportunity to investigate. BnR360 replies Monday to Friday during business hours, 7:00 a.m. to 4:00 p.m. EST. BnR360 does not operate a continuous security hotline.