Security Assurance Plan (SAP)

Document purpose. This Security Assurance Plan explains the controls, processes, and evidence that Intuitem provides to protect customer data and ensure the availability, integrity, and confidentiality of the CISO Assistant platform.

Intended audience. Security, risk, compliance, procurement, and technical stakeholders at customer organizations.

Last updated: 2026-07-22

1) Scope & Applicability

This plan covers Intuitem’s SaaS offering of CISO Assistant and the associated managed infrastructure, operations, and support services. Customer-managed (on-premises) deployments are covered where explicitly noted (see §18 and §22).

2) Security Governance

Frameworks: Our program is aligned with NIST CSF for cybersecurity management and OWASP ASVS for application security.
Policies & ownership: Security policies are owned by Intuitem leadership and reviewed at least annually.
Roles: A designated Data Protection Officer (DPO) oversees data protection and privacy. Contact: contact@intuitem.com. To report a security issue, please use: security@intuitem.com
Defense-in-depth: We apply a multi-layer approach combining preventive, detective, and corrective controls.

3) Risk Management & Governance

Process: We maintain an enterprise risk register that captures security, operational, and compliance risks.
Methodology: Risks are assessed and rated using a combination of likelihood and impact, following ISO 27005 principles.
Reviews: Risks are reviewed quarterly and after significant changes to systems or threat landscape.
Mitigation linkage: Each high/critical risk has mapped mitigation measures, tracked to completion.
Customer impact: Where relevant, risks and mitigations affecting customers are communicated through our account management process (support portal).

4) Architecture & Hosting

Primary region: France, operated across two cloud service providers (CSPs): Scaleway and OVH.
Secondary region: Netherlands (used for resilience and disaster recovery).
Platform: Kubernetes for orchestration, high availability, and auto-scaling.
Network exposure: Only HTTPS (port 443) is publicly exposed; all other inbound traffic is denied by default.
Encryption: TLS 1.3 for encryption-in-transit with automatically renewed Let’s Encrypt certificates—Encryption-at-rest at the disk level using a Server-Side Encryption with provider-managed keys.
Special deployments: for specific cases, the hosting location can be agreed on with the customers to accommodate their needs.

5) Data Isolation & Multi-Tenancy

No data mixing: Customer data is never mixed. Each tenant runs as a dedicated, isolated application instance with separate storage volumes.
Deployment-level controls: Isolation is enforced at the deployment and storage layers to prevent cross-tenant access.
Decoupled storage: Data is separated from compute to support fast rebuilds and disaster recovery.
Snapshots: Periodic volume snapshots are taken for recovery readiness.

6) Access Control & Identity

Least privilege & need-to-know: Access to production is restricted to a small subset of engineers.
MFA everywhere: Multi-factor authentication (MFA) is enforced for all privileged access.
Customer data access governance: Any access to customer data in production requires explicit authorization (e.g., a support ticket for debugging) and time-bound access.
Product IAM (SaaS and on-premises): CISO Assistant provides SSO (SAML/OIDC), granular role-based access control, MFA, and SCIM-based user provisioning, so customers can plug in their own identity provider and enforce their IAM policies within the product.

7) Data Retention & Secure Deletion

Retention periods:
- Production data: retained for the lifetime of the subscription and deleted within 30 days after termination unless otherwise agreed.
- Backups: retained for 14 days before automated secure deletion.
- Logs: retained per operational needs (default 90 days), anonymized or deleted thereafter.
Deletion method: Data is securely deleted using cryptographic erasure or provider-verified secure delete.
Customer control: On request, customers can request early deletion of specific datasets.

8) Secure Development Lifecycle (SDLC)

Code review: All changes undergo peer review. We apply stricter controls for third-party contributions to our open-source components.
SAST & DAST: Automated static (developer workstations and CI/CD) and dynamic analysis to detect implementation flaws and runtime issues.
Software Composition Analysis (SCA): CI/CD pipelines continuously scan third-party libraries for vulnerabilities and license issues. Dependency versions are pinned; LTS versions are preferred and security patches applied promptly. SBOMs can be provided on request.
Credential leakage detection: Commits are scanned to prevent secrets exposure; credentials are rotated immediately if detected.
Contribution controls: Repository-level protections limit who can contribute, approve, merge, or trigger releases.
Security training: Engineers receive regular training on secure coding practices and emerging threats.
Threat modeling: Before each new feature, we run structured threat-modeling to identify security and operational risks.
Continuous verification: These security checks run continuously across commits and releases, and identified issues are fixed as part of the regular development flow — not deferred to periodic reviews.

9) Privacy by Design & Default

Principle: Privacy is embedded into our development and operational processes from the outset.
Data minimization: Only collect and store the minimum personal data needed for service delivery.
Pseudonymization/anonymization: Apply where feasible for analytics, testing, and troubleshooting.

10) CI/CD & Change Management

Secure pipelines: Releases are built and deployed via controlled CI/CD pipelines with staged environments.
Separation of duties: Build, approval, and deploy steps are segregated and logged.
Change logging: All changes are tracked and auditable (who, what, when).

11) Secrets & Key Management

Secrets storage: Operational secrets are stored in managed key store systems (eg, GitHub secret manager) or encrypted configuration stores.
Rotation: Keys and credentials are rotated following policy or after potential exposure.

12) Cryptography Policy

Encryption-at-rest: AES-256 or equivalent industry-approved algorithms.
Encryption-in-transit: TLS 1.3 with strong cipher suites, maintaining a good balance between security and browser compatibility.
Key management: Keys are generated, stored, and rotated in secure systems; never hard-coded in source code. We have automated controls at the CI/CD level to double-check this.
Lifecycle: Keys are retired and destroyed securely at the end of their lifecycle.

13) Logging, Monitoring & Detection

Coverage: Demo and production environments are continuously monitored for availability, performance, regressions, and security events.
Retention & protection: Logs are retained per policy and protected from tampering.
Alerting & response: Alerts are triaged by on-call staff with documented runbooks.

14) Vulnerability & Patch Management

Scanning: Regular vulnerability scans are performed on application components and container images. This information is publicly available through our GitHub repository or by scanning the application Docker images.
Prioritization: Findings are risk-rated and remediated within target service levels.
Patch cadence: We operate a strict schedule to patch the application, underlying systems, and dependencies. Findings are prioritized by severity.
Advisories: Significant vulnerabilities and their fixes are communicated through release notes and security advisories on our public repository, so both SaaS and on-premises customers are informed.

15) Incident Response (IR)

IR Plan: A maintained Incident Response Plan defines detection, escalation, communication, and remediation procedures.
Exercises: We conduct periodic incident simulations for team readiness.
Forensics: We retain tooling and playbooks to scope incidents and support root-cause analysis.
Customer notification: Customers are notified of incidents affecting their data or service without undue delay, in line with GDPR requirements for personal data breaches.

16) Business Continuity & Disaster Recovery (BC/DR)

Provider diversity: Services run on two independent CSPs/infrastructures. If one provider is impaired, we can activate disaster-recovery mode and fail over to the other.
Backups: Periodic backups every 24 hours with a 14-day retention.
Restores: DR procedures and restores are tested regularly.

17) Network & Infrastructure Security

Zero-trust principles: Cluster control-plane access is tightly restricted. Access requires MFA as part of the general guideline.
Ingress filtering: Only required services are exposed (HTTPS/443).
Hardening: Kubernetes and workloads are configured following industry best practices.

18) Responsibilities & Contacts (Shared Responsibility Model)

Area	SaaS	On-premises
Hosting, hardening, network security	Intuitem	Customer
Application security fixes & releases	Intuitem	Intuitem (delivery) / Customer (application)
Backups, PRA/PCA	Intuitem	Customer
Infrastructure monitoring & logging	Intuitem	Customer
User accounts, roles, MFA in the product	Customer	Customer

Customers configure access settings to align with internal policies and organisation setup, and can generate an export of their data at any time for backup or portability.
Report suspected security issues to security@intuitem.com promptly.
Interlocutors: named contacts (security, technical, account) are identified for each engagement and communicated contractually, for both deployment modes.
For self-hosted/on-prem deployments, operate and secure the infrastructure stack per vendor guidance (see §22).

19) Compliance & Certification Roadmap

Current: Alignment with GDPR, CCPA; use of ISO 27001 certified providers.
Planned: Progressing toward ISO 27001 certification for Intuitem’s own ISMS, targeted for Q4/2026.

20) Third-Party Risk Management

Assessment: Third-party services are evaluated for security posture and data-handling obligations.
Contractual controls: Data processing and confidentiality clauses are included where applicable.

21) Assurance & Independent Testing

External penetration testing: An annual penetration test is conducted by an independent, unbiased third party; the report and remediation actions are publicly available on our website.
Open source transparency: CISO Assistant is fully open source — including the enterprise edition, under a separate license — so customers can run the code and conduct their own security reviews.
Vulnerability disclosure: Instructions for reporting security issues are available in our public repository.

22) Deployment Options

SaaS (managed by Intuitem): Covered by this plan end-to-end.
On-premises (PRO plan): The customer operates and secures the hosting environment; Intuitem supports this as follows:
- Hardening: Deployment guides and reference configurations for a secure setup (network exposure, TLS, container runtime).
- Access control: The product’s built-in IAM — SSO, RBAC, MFA, SCIM (see §6) — applies identically on-premises.
- Updates & patches: Security fixes are delivered through versioned releases; advisories for significant issues are published via our public repository (see §14). Customers are responsible for applying updates promptly.
- Supervision & backups: Recommendations for monitoring, logging, and backing up the application and its database are provided in the deployment documentation.
- Support: PRO subscriptions include Intuitem support for upgrades and security-related questions.

23) Change Control, Maintenance & Review

This SAP is reviewed at least annually or following material changes to systems, providers, or regulations.

Contacts

Security: security@intuitem.com
Privacy (DPO): contact@intuitem.com
General: contact@intuitem.com