Trust & Security

01Security and trust by design

Binnovy treats security, privacy, accountability and evidence as design requirements rather than after-the-fact controls. The exact safeguards applicable to a customer depend on the contracted service, deployment architecture, data classification and risk profile. This page describes Binnovy’s baseline approach; specific contractual security commitments appear in the relevant agreement, security schedule or verified assurance report.

02Governance and accountability

Binnovy designs systems so that material actions can be attributed to authorized identities, policy decisions can be reviewed, and significant events can be logged and investigated. Where a product includes governance gates, evidence ledgers or approval workflows, those controls are intended to support traceability and accountability; their exact configuration and assurance level are service-specific.

03Identity and access control

• Role-based and least-privilege access appropriate to the service and administrative function.
• Strong authentication controls for privileged access and support for multi-factor authentication where provided by the service.
• Lifecycle controls for provisioning, changing and revoking access.
• Logging and review of privileged or security-relevant actions appropriate to the deployment.

04Encryption and data protection

Binnovy uses current, appropriate encryption controls for data in transit and, where supported by the applicable storage/service layer, at rest. Encryption design, key management, customer-managed-key options and cryptographic parameters vary by deployment and are stated in technical or contractual documentation where material. Personal data is handled in accordance with the Privacy Notice and DPA.

05Data residency and sovereignty

Binnovy supports architectures intended to meet different residency and sovereignty requirements, including region-bound, in-country, dedicated and, where expressly designed and contracted, isolated or air-gapped deployments. Residency is treated as a verifiable deployment property: Binnovy will not claim that data stays in a jurisdiction or that no external sub-processor can access it unless the actual architecture, vendor chain and operational procedures support that claim.

06Secure development and change management

• Security and privacy requirements considered during design and material product changes.
• Code review, dependency management, testing and release controls appropriate to the development workflow.
• Vulnerability triage and remediation based on severity, exploitability and customer risk.
• Environment separation and controlled administrative access.
• Change records and rollback or recovery procedures proportionate to service criticality.

07Monitoring, logging and auditability

Security and operational events are logged to the extent appropriate for the service and risk. For products that provide tamper-evident or hash-linked evidence capabilities, Binnovy may use those controls to strengthen integrity and reconstructability. Binnovy does not describe an audit record as independently verifiable unless the specific implementation provides that capability and the claim can be demonstrated.

08Incident response and breach management

Binnovy maintains incident-response procedures for triage, containment, investigation, remediation, recovery, evidence preservation and communications. Personal-data incidents are handled under the Privacy Notice and DPA. Contractual severity levels, response targets and notification times apply only where stated in the relevant service or security agreement.

09Resilience, continuity and recovery

Binnovy applies backup, recovery and continuity measures proportionate to the relevant service and architecture. Recovery objectives, redundancy, failover and disaster-recovery commitments are service-specific and should be stated in the commercial agreement or service-level documentation rather than assumed from this general page.

10Supplier and sub-processor security

Third parties that may access or process protected data are subject to risk-based review and written contractual controls. Approved sub-processors are governed by the DPA and public Sub-processors page. Binnovy’s goal is to minimize unnecessary third-party access and align vendor selection with customer residency and sovereignty requirements where contractually required.

11Responsible AI and human oversight

Binnovy’s AI-related controls are intended to support lawful scope, authorization, traceability, human oversight and risk management. AI capabilities must not be used for prohibited conduct under the Code of Conduct or Acceptable Use Policy. High-impact or regulated uses require the customer to apply the human review, validation, approvals and sector-specific controls required by law and the applicable agreement.

12Human-rights and conflict safeguards

Binnovy applies the Code of Conduct to technology access and business relationships. We do not knowingly support parties engaged in genocide, crimes against humanity, war crimes, unlawful armed aggression or other grave human-rights or international-humanitarian-law violations, and we may apply enhanced due diligence, restrictions or termination in conflict-affected or high-risk contexts.

13Standards and assurance claims

Binnovy may map its controls to recognized frameworks and standards relevant to the service, such as ISO/IEC 27001, ISO/IEC 27701, NIST cybersecurity guidance, OWASP practices or other sector frameworks. A mapping does not mean Binnovy is certified, audited or compliant with a specific standard unless Binnovy publishes a current, independently verifiable certification or assurance report covering the relevant scope. Customers should rely on current evidence rather than marketing language.

14Responsible vulnerability disclosure

If you believe you have identified a security vulnerability, report it through /contact and mark the message "Security Vulnerability". Do not access data that is not yours, degrade services, use destructive techniques, extort Binnovy or customers, or publicly disclose an unresolved vulnerability before reasonable remediation coordination. Binnovy does not seek action against good-faith researchers who act lawfully and comply with the published disclosure rules.

15Shared responsibility

Security is shared. Customers are responsible for their users, access assignments, credentials, endpoint security, connected systems, configurations, data classification, lawful use, integrations and any customer-managed infrastructure. Binnovy is responsible for the controls assigned to it by the applicable service architecture and agreement.

16Contact

Security, trust and assurance enquiries may be submitted through /contact. Contracted customers may use their designated support or security channel for incident, assurance and evidence requests.