This Security Exhibit describes the baseline technical and organisational measures C4CI applies to C4CI Arch. It supports the Enterprise Master Services Agreement, Data Processing Addendum, Privacy Policy, and customer security review.
1. Security Program
C4CI maintains a security program designed for a multi-tenant B2B SaaS product that processes infrastructure metadata, architecture evidence, billing records, identity data, support data, and customer-controlled content.
The program is risk-based and evolves as the product, customer base, threat model, and regulatory expectations change.
2. Governance
C4CI maintains ownership for security controls, product changes, incident response, access review, legal-document rollout, and operational runbooks.
Security decisions are documented through architecture decisions, runbooks, code review, test evidence, and operational records where applicable.
3. Identity and Access Control
Baseline controls include:
- authenticated access for protected product surfaces;
- role-based access control for user, organisation, and platform-admin operations;
- organisation-scoped tenancy for customer workspaces;
- least-privilege integration posture where available, including Reader-first cloud discovery;
- administrator access limited to personnel and systems with operational need;
- removal or restriction of access when no longer required;
- customer responsibility for identity-provider configuration, user offboarding, and role assignment.
4. Tenant Isolation
Arch is designed to keep organisation data scoped to the relevant tenant and authorised users. Product APIs, frontend routing, database queries, and integration flows are expected to preserve organisation boundaries.
Security findings that could expose another tenant's data are treated as high priority.
5. Encryption and Secrets
C4CI uses encrypted transport for supported production routes and relies on platform encryption controls for storage layers where available.
Secrets and credentials should be stored in designated secret-management systems or encrypted product stores, not in free-text prompts, comments, or support messages. Customer is responsible for using least-privilege credentials for connected systems.
6. Logging and Auditability
C4CI records audit and operational events for security, legal acceptance, billing, support, product-control, and administrative workflows where implemented.
Audit records may include user identifiers, organisation identifiers, event type, timestamps, content hashes, request metadata, and relevant product context. Audit records are protected according to the Privacy Policy and Data Processing Addendum.
7. Secure Development
C4CI's secure development practices include:
- version-controlled source changes;
- code review and automated tests for product changes;
- targeted validation for legal registry and content-hash integrity;
- dependency review and vulnerability management where tooling is configured;
- structured architecture decisions for material changes;
- separation between shared standards, product behavior, and environment configuration;
- avoidance of invented operational or customer data in product artifacts.
8. Infrastructure and Operations
The platform is operated using cloud and Kubernetes infrastructure. Operational controls include runbooks, deployment validation, backup and restore practices, health checks, logging, monitoring, and incident-response workflows.
The product architecture targets Microsoft Azure, AKS, Key Vault, database services, Kubernetes addons, and region-specific deployment choices documented in product architecture decisions.
9. Vulnerability Management
C4CI triages vulnerabilities based on severity, exploitability, affected data, tenant isolation impact, operational exposure, and availability impact.
External vulnerability reports are handled under the Vulnerability Disclosure Policy. C4CI may prioritise fixes, mitigations, configuration changes, or customer notifications based on risk.
10. Incident Response
C4CI maintains an incident-response process covering:
- detection and triage;
- severity assignment;
- containment;
- investigation;
- remediation;
- customer communication where required;
- post-incident review.
Customer-impacting security incidents are communicated according to the Data Processing Addendum, Support and SLA Policy, order form, and applicable law. C4CI maintains an internal security and privacy incident-response runbook that covers customer-impact assessment, personal-data-breach assessment, phased customer notices, evidence preservation, and post-incident review.
11. Backup and Recovery
C4CI maintains backup and restore practices for relevant platform components. Backup scope, schedules, retention, and recovery objectives may vary by environment and component.
Customer-specific recovery commitments apply only when stated in an order form or Support and SLA Policy.
12. Personnel and Confidentiality
Personnel with access to customer data or production systems are expected to be bound by confidentiality obligations and to access systems only for authorised business purposes.
C4CI may use contractors, advisers, or subprocessors where needed, subject to confidentiality and data-protection obligations appropriate to their role.
13. Customer Responsibilities
Customer is responsible for:
- securing its identity provider, cloud accounts, repositories, billing accounts, and connected systems;
- assigning least-privilege roles;
- rotating credentials and removing stale access;
- reviewing AI-assisted, architecture, drift, and remediation outputs before relying on them;
- reporting suspected incidents to C4CI promptly;
- avoiding unnecessary secrets and regulated data in free-text fields.
14. Certifications and Reports
SOC 2, ISO 27001, PCI, or other certifications apply only when C4CI has completed and published the relevant certification or report. Until then, C4CI may provide architecture summaries, control descriptions, test evidence, and security questionnaires as trust evidence.
15. Contact
Security questions should be sent to support@c4ci.io. Vulnerability reports should follow the Vulnerability Disclosure Policy.