Trust & Compliance

Security and governance built for high-stakes workloads

Bormacc develops institutional real estate and delivers sovereign private cloud environments designed for regulated, mission-critical, and high-value workloads. We treat trust as an engineering and operating discipline: physical security, deterministic technical controls, evidence-ready operations, and clear accountability across the lifecycle.

This page is an overview of our trust and compliance posture. It is not a contract, warranty, certification, or representation that every site, service, or deployment option meets a particular standard. Your specific controls, scope boundaries, service levels, and audit rights are defined in the applicable agreements and order documents.

How we define "sovereign" (in enforceable terms)

Sovereignty is not a marketing label. In our model, sovereignty is expressed through enforceable and auditable controls across four dimensions:

• Boundary and custody: clear physical boundary options (suite/cage/hall/building) depending on deployment, with defined custody workflows for access, break/fix, and chain-of-custody.
• Administrative control: access governance that limits privileged access paths, records administrative actions, and enforces separation of duties aligned to tenant identity integration.
• Key custody and encryption controls: encryption and key management patterns designed to support tenant governance requirements; key custody expectations documented per engagement (roles, approvals, logging).
• Controlled data movement: ingress/egress and integrations treated as governed interfaces, with audit-relevant telemetry and event records for approved data movement paths.

Shared responsibility and scope boundaries

Security and compliance are shared responsibilities. Controls and ownership vary based on what is being delivered (facility, platform, managed services, tenant-owned equipment, etc.). For each engagement, we document the items below.

Where customers require deeper evidence, reporting cadence and export mechanisms are defined in the applicable documentation and agreements.

• In-scope systems and services (what is covered).
• Out-of-scope systems and services (what is not covered).
• Control ownership (Bormacc, customer, or shared).
• Evidence expectations (what artifacts demonstrate controls are operating).

Physical security and facility controls (data-center discipline)

Our environments are designed and operated with the discipline expected of mission-critical infrastructure, which may include the following controls depending on the site and engagement. Physical controls and procedures are scoped by site and engagement and may vary depending on tenant requirements and local conditions.

• Controlled physical access and role-based authorization.
• Visitor management and escort procedures where required.
• Video surveillance practices and retention aligned to policy and applicable requirements.
• Environmental monitoring and operational procedures for resiliency.
• Documented maintenance, remote-hands workflows, and change control for facility-side actions.

Platform and network security (cloud-provider discipline)

Our private cloud environments are designed to support strong control execution and auditability, which may include the capabilities below depending on the deployment. Where managed services are provided, the service description and scope boundaries define what we operate versus what the customer operates.

• Network segmentation and boundary enforcement (e.g., zone separation, controlled gateways, and default-deny principles where appropriate).
• Identity and access management controls (least privilege, MFA/strong authentication patterns, privileged access workflows).
• Secure configuration management and baseline hardening practices.
• Vulnerability management and patch governance aligned to risk and operational constraints.
• Centralized logging, alerting, and monitoring aligned to operational readiness.

Evidence and audit readiness (what "good" looks like)

We build toward evidence-ready operations. Practical examples of evidence artifacts (where applicable to scope) can include the items below. Evidence availability, format, and cadence depend on the engagement and applicable confidentiality requirements.

• Access governance records (physical and logical).
• Change management records and approvals.
• Vulnerability scan outputs and remediation tracking.
• Incident response procedures and event timelines (when triggered).
• Configuration exports and control attestations tied to defined scope boundaries.

Compliance alignment (frameworks and customer requirements)

Customers and stakeholders often require alignment to widely recognized frameworks and regulatory expectations. Our control design and operating model are structured to support common requirements that may include (depending on scope):

Important: references to standards or frameworks describe alignment goals and control design approaches and do not necessarily mean a certification or attestation exists for every environment. Where third-party reports or assessments are available and relevant, they are provided under appropriate confidentiality.

• Information security management and governance programs (e.g., ISO/IEC-aligned approaches).
• Third-party assurance expectations (e.g., SOC-style control domains and evidence).
• Regulated workload expectations (e.g., NIST-aligned controls and zero-trust concepts).
• Sector-specific requirements where applicable (e.g., healthcare, payments, public sector).

AI governance and "no-training by default"

The systems we power are used for real-world outcomes. Governance matters.

• No-training by default: we do not train shared/generalized models on customer non-public data by default.
• Opt-in only: any training or fine-tuning use of customer data (if offered) must be explicitly agreed in writing, scoped, and governed.
• Separation and auditability: we differentiate inference access from training activities and design controls so that data use can be governed and evidenced.

Third-party risk and supply-chain discipline

We assess vendors and service providers appropriate to their role and the risk they introduce. Where third parties support operations, we expect contractual confidentiality, security obligations, and service standards appropriate to the engagement.

Business continuity, resiliency, and operational discipline

Resiliency is part of trust. Depending on the environment and contract scope, this may include operational practices such as:

• Documented backup and restoration procedures (where applicable).
• Tested recovery workflows.
• Incident management and escalation paths.
• Monitoring and maintenance schedules.

Questions, documentation requests, and responsible disclosure

For trust, compliance, or documentation requests, contact: info@bormacc.com.

If you believe you have discovered a security issue, please provide a clear description, affected page/system (if known), and steps to reproduce. Do not include sensitive personal information in your message.