Security Policy

1. Security governance and risk

• Security responsibilities are assigned for platform operation, access, incident handling, vulnerability remediation, and customer communication.
• Risks are assessed in light of the sensitivity of credentials and secrets, tenant and resource boundaries, internet exposure, dependencies, deployment model, and business impact.
• Personnel and service providers receive access only where needed and are subject to confidentiality and security requirements.
• Policies, threats, material incidents, and significant platform changes are reviewed and improvements are prioritised by risk.

2. Architecture and data protection

• Supported hosted traffic is encrypted in transit using current transport security configurations.
• Stored credential and secret data is encrypted at rest in supported hosted components.
• Authorisation is enforced through organisations, teams, workspaces, vaults, roles, permissions, and resource-level checks.
• STARTER and PRO tenants operate in shared Kubernetes clusters with logical isolation and Kubernetes network policies. ENTERPRISE Customers receive a dedicated, segregated Kubernetes cluster unless a separately approved private-deployment design is documented in the Order Form.
• Hosted deployments use an available AWS region selected according to the Customer’s requirements and recorded in the applicable Order Form or service schedule. kubbeevault does not impose one default customer-data region for every deployment.
• Audit history records relevant creation, access, change, sharing, and deletion activity according to the selected plan and retention configuration.
• Hosted deployments use segmented application components and managed infrastructure controls appropriate to the deployment; Enterprise private deployments have responsibilities defined in their Order Form.
• For supported hosted deployments, the proposed STARTER profile uses one application replica in one availability zone with automatic rescheduling and two database instances across two availability zones; its target RTO is no more than 30 minutes and target RPO is no more than 5 minutes. The proposed PRO profile uses two application replicas across two availability zones and two database instances across two availability zones; its target RTO is no more than 10 minutes and target RPO is no more than 1 minute. The proposed ENTERPRISE profile uses three application replicas across three availability zones and three database instances across three availability zones; its target RTO is no more than 5 minutes and target RPO is no more than 1 minute.
• These recovery figures are service objectives, not guarantees or service-level commitments unless incorporated into the applicable Order Form or service-level schedule. Data location, key-management options, tenant-isolation details, backup design, recovery procedures, and retention remain deployment-specific. Customer-managed and private deployments require separately agreed responsibilities and objectives.

3. Identity and access management

Native authentication is available. Single sign-on is not represented as generally available unless an Order Form or current product documentation says otherwise. Administrative and production access follows least-privilege principles, is limited to authorised personnel, and should use strong authentication and auditable access paths.

• Customers must use individual accounts, appropriate roles, prompt offboarding, secure endpoints, and secret rotation.
• Customers are responsible for their identity provider, recovery factors, integrations, API clients, browser environment, and any Customer-managed deployment.
• kubbeevault support will not request a password, private key, token, or complete secret through an ordinary email or website form.

4. Secure operation and development

• Changes are reviewed, tested in proportion to risk, and deployed through controlled build and release workflows.
• Dependencies, configuration, code, and infrastructure are assessed for vulnerabilities using available automated and manual techniques.
• Security patches and verified vulnerabilities are prioritised according to severity, exploitability, exposure, and customer impact.
• Logs and monitoring support availability, authentication, authorisation, audit, abuse prevention, and incident investigation.
• Backups and redundancy are maintained for supported hosted deployments according to the applicable service schedule; restoration capability is tested at a frequency appropriate to the service risk.
• Backup, incident-response, and deletion procedures are documented in internal Confluence runbooks. Related binding commitments arise only where stated in the applicable Order Form or service-level schedule.
• Security testing and vulnerability reports generated for a Customer may be shared with that Customer under the applicable confidentiality, scope, and delivery terms. A report is not a certification and applies only to its stated systems, methods, and test date.
• Secrets used to operate kubbeevault are stored and accessed through controlled mechanisms and are not committed to public source repositories.

5. Availability, support, and plan differences

• STARTER: SaaS, email support, best-effort availability, proposed target RTO of no more than 30 minutes, and proposed target RPO of no more than 5 minutes unless the Order Form states a binding commitment.
• PRO: SaaS, priority 8×5 support, the availability target stated in the current pricing description or Order Form, proposed target RTO of no more than 10 minutes, and proposed target RPO of no more than 1 minute.
• ENTERPRISE: SaaS or approved private deployment, 24×7 support, proposed target RTO of no more than 5 minutes, proposed target RPO of no more than 1 minute, and the negotiated availability, initial-response, maintenance, recovery, and service-credit terms in the Order Form.
• Public plan descriptions do not replace a signed service-level schedule. Exclusions commonly include announced maintenance, Customer-controlled systems, unsupported configurations, force majeure, and external providers outside kubbeevault’s reasonable control.

6. Incident response

kubbeevault maintains a process to identify, triage, contain, investigate, eradicate, recover from, and review security incidents. Customers must promptly report suspected compromise and preserve relevant information without placing live secrets in ordinary communications.

For a confirmed Personal Data Breach affecting Customer Personal Data, the notice and cooperation commitments in the Data Processing Agreement apply. Other material service-security notifications follow the Order Form and applicable law. Public statements are coordinated to avoid increasing risk or compromising an investigation.

7. Assurance and truthful claims

kubbeevault does not claim ISO certification, SOC examination, PCI DSS compliance, a completed independent penetration test, post-quantum assurance, or another formal attestation unless the specific current report or certificate is made available and its scope is stated. Roadmap items are not production controls.

Enterprise Customers may request available architecture, security, and commercial review materials under confidentiality. Access to detailed test results, source code, infrastructure, or another customer’s information is not provided unless expressly agreed and safely scoped.

8. Reporting security concerns

Potential vulnerabilities should be reported under the Vulnerability Disclosure Policy to [email protected]. Customer incidents should use the support and escalation contacts in the Order Form. Do not publish an unremediated vulnerability or include live Customer secrets in a report.