# CISO Assistant Community Edition: A Self-Hosted GRC Hub With 200+ Frameworks > CISO Assistant is an API-first, Django-based platform that decouples compliance from controls and maps 200+ frameworks automatically. It installs with a Docker Compose script, and the AGPL licence shapes who can reasonably self-host it. **intuitem/ciso-assistant-community** — CISO Assistant is a one-stop-shop GRC platform for Risk Management, AppSec, Compliance & Audit, TPRM, BIA, Privacy, and Reporting. It supports 200+ global frameworks with automatic control mapping, including ISO 27001, NIST CSF, SOC 2, CIS, PCI DSS, NIS2, DORA, GDPR, HIPAA, CMMC, and more. - Repository: https://github.com/intuitem/ciso-assistant-community - Website: https://intuitem.com - Stars: 4,471 · Forks: 847 - Language: Python - License: NOASSERTION - Published: 2026-09-09 · Updated: 2026-09-09 · Language: en - Canonical page: https://hysenlabs.com/projects/intuitem-ciso-assistant-community ## What CISO Assistant Community actually replaces Most GRC work inside a mid-sized company happens in three disconnected places: a spreadsheet of controls, a document store of policies and evidence, and a ticketing system for remediation. The README frames the project as a reaction to exactly that, describing "tool fragmentation, data duplication, and a lack of intuitive, integrated solutions" as the problems its authors hit as practitioners. CISO Assistant is their attempt to collapse those into one Django application with a single object graph. The intended audience is the internal compliance function: whoever owns the ISMS, runs audits, tracks third-party risk, and answers the same questionnaire for the fourth time. It is not aimed at a one-person startup that needs a SOC 2 checklist. The feature list in the README is broad on purpose, covering audit and campaign management, policies and evidence, risk registers with acceptance workflows, EBIOS RM, business impact analysis, cyber risk quantification, third-party risk, and action plan tracking. That breadth is the product's argument and also its cost: you are adopting a platform, not a utility. ## The decoupling idea and how objects link The design choice that distinguishes this project from most compliance tools is stated plainly in the README: it "explicitly decouples compliance from cybersecurity controls, enabling reusability across the platform." In practice that means a control is a first-class object that exists independently of any framework requirement. Framework requirements point at controls, and the same control can satisfy requirements in ISO 27001, NIST CSF and SOC 2 at once. When you implement it once, the mapping propagates. That is why automatic mapping matters here rather than being a marketing bullet. With 200+ frameworks in the box, the value is not the count. The value is that a control you already assessed does not have to be reassessed because a customer sent you a different framework. The README also describes an "open format to customize and reuse your own objects and frameworks" and custom frameworks "via a simple syntax", which is the escape hatch when a regulator hands you something that is not in the library. The architecture is visible in the repository layout rather than described in prose. There is a backend directory, a frontend directory, a cli directory, a dispatcher, an integration folder, charts for Kubernetes, and a config directory the README points to as the config builder for self-hosting. The README describes the project as "API-first", with the API serving both the UI and external automation, and the repository links a Swagger-based API reference. If you plan to drive this from scripts or a CI pipeline, that is the surface to read first. ## Installing CISO Assistant with Docker Compose The README gives two paths. The first is a hosted trial at intuitem.com/trial. The second is self-hosting, and it assumes Docker and Docker Compose are already present. Clone the repository on a single branch: ```bash git clone --single-branch -b main https://github.com/intuitem/ciso-assistant-community.git ``` Then run the starter script for your platform. On Linux or macOS it is the shell script; on Windows the README specifies Docker Desktop with WSL2 and the PowerShell script, which it says will feed Docker Desktop on your behalf. ```bash ./docker-compose.sh # Linux/MacOS ./docker-compose.ps1 # Windows ``` The compose file pulls prebuilt images from ghcr.io and starts several services. The backend image runs the Django application with a healthcheck against http://backend:8000/api/health/, a start period of 150 seconds and 30 retries, so expect a slow first boot. A separate huey service runs the same image with a different entrypoint, `python manage.py run_huey -w 2 --scheduler-interval 60`, which is the background task worker. The backend environment sets CISO_ASSISTANT_URL to https://localhost:8443, so that is the address to open once the stack is healthy. A Qdrant service is referenced through QDRANT_URL=http://qdrant:6333, and both the backend and the worker mount ./db from the host for persistent data. The compose file is deliberately hardened: read_only root filesystems, cap_drop of ALL, no-new-privileges, and tmpfs mounts for /tmp. That is good default posture, but it also means ad-hoc changes inside a running container will not survive, and the README notes the compose file can be adjusted to pass extra parameters such as mailer settings. Two warnings in the README are worth taking literally. If images warn about platform mismatch with your host, either raise an issue or use docker-compose-build.sh to build for your architecture. And do not run the main branch in production, because the README describes it as the merge upstream that can carry breaking changes; use tags or prebuilt images instead. ## Where the community edition will frustrate you The repository contains an enterprise directory alongside the community code, and the README's own framing is that the project evolves "with input from users and customers". Read that as a signal: the community edition is the open core, and the boundary between what lives there and what lives in enterprise/ is not spelled out in the README. If a capability you need turns out to sit on the other side of that line, you will discover it after deployment, not before. The related searches around community versus pro exist for a reason. Operationally, this is a multi-service stack, not a single binary. You are running a Django backend, a Huey worker, a frontend, and Qdrant, with a database directory bind-mounted from the host. The 150-second healthcheck start period is a fair warning about cold starts. The README does not document rollback, backup, or restore procedures, and it does not document an upgrade path between releases; the update-ciso-assistant.sh script exists in the tree, but the README does not describe what it does in enough detail to plan a maintenance window around it. If you need a documented disaster recovery story before you can put compliance data somewhere, that gap is the one to close first. There is also a licensing wrinkle. The repository tree contains LICENSE-AGPL.txt and a Contributor License Agreement, while the repository metadata reports the licence as NOASSERTION. Those two facts do not contradict each other, but they mean you cannot take the licence at face value from a badge. Anyone planning to embed or modify this and redistribute it needs to read the actual file in the tree. ## CISO Assistant against a commercial GRC suite The obvious alternative is a commercial GRC platform, and the difference is not feature count. It is who carries the operational burden. A commercial suite arrives as a managed service: the vendor handles upgrades, backups, availability, and the mapping library. CISO Assistant Community hands all of that to you. In exchange you get the data on your own hardware, no per-seat negotiation, and the ability to extend the object model because the whole thing is in the repository. A second alternative is the spreadsheet, and it deserves a fair hearing. If your scope is one framework and a few dozen controls, a well-built spreadsheet is cheaper to run than a Django stack with a worker queue and a vector database. CISO Assistant starts paying off when you are answering to multiple frameworks simultaneously and the same control keeps reappearing under different names. That is the specific condition where automatic mapping stops being a feature and starts being the reason you switched. A third comparison worth making is against narrow point tools: a dedicated TPRM questionnaire product, or a dedicated vulnerability tracker. CISO Assistant overlaps with all of them, and the README's positioning as a "central hub" is an argument that overlap is the point. The risk of a hub is that it is adequate at many things and best-in-class at none. If your team's hardest problem is third-party risk specifically, evaluate the TPRM section of CISO Assistant against a specialist before assuming the hub wins. ## Maintenance cost, releases and licence exposure Release cadence is visible in the tags: v3.21.3, v3.21.4, then v4.0.1, with the most recent push to the repository on 2026-09-09. A major version bump from 3.x to 4.x is the kind of event that usually carries migration work, and the README does not describe one. Budget for reading release notes before you jump a major version, and for the possibility that a self-hosted upgrade needs manual database attention given the ./db bind mount. The compose file pins `latest` for the backend and worker images with pull_policy: always. That combination means a restart can silently change the version you are running. For anything holding audit evidence, that is a bad default. Pin a specific release tag in your own copy of the compose file rather than relying on latest. On licence: the tree carries LICENSE-AGPL.txt and a Contributor License Agreement, while the repository metadata reports NOASSERTION. AGPL-3.0 is a strong copyleft licence with a network clause, which in plain terms means offering a modified version as a service can trigger source disclosure obligations. This is not legal advice and the exact scope depends on your deployment; the point is that the licence file, not the badge, is what your counsel needs to read. ## Conclusion Adopt CISO Assistant Community if you run an internal GRC or ISMS function, want your compliance data on your own hardware, and are comfortable operating a Django stack with a Huey worker and Qdrant behind it. Do not adopt it if you need a vendor to carry the operational load, if you cannot accept AGPL-3.0 obligations on a modified deployment, or if your requirement is a single framework with a handful of controls; a spreadsheet or a narrow point tool will cost less to run. Before committing, verify three things: that the prebuilt images match your host architecture, that the tag you deploy is a release tag rather than main, and that the licence file in the repository matches what your legal review expects, since the repository metadata reports NOASSERTION while the tree carries LICENSE-AGPL.txt. ## FAQ ### What is CISO Assistant? It is a GRC platform covering risk management, compliance and audit, third-party risk, business impact analysis, privacy and reporting, built as a Django application with an API-first design. The README describes it as a central hub that decouples compliance from cybersecurity controls so controls can be reused across frameworks. ### Is CISO Assistant free? The community edition is published on GitHub under an open licence, with LICENSE-AGPL.txt in the repository tree and a Contributor License Agreement alongside it. The repository also contains an enterprise directory and the README links a SaaS free trial, so the community edition is free to self-host while other editions exist separately. ### How do I install CISO Assistant Community Edition? Clone the repository with git clone --single-branch -b main, then run ./docker-compose.sh on Linux or macOS, or ./docker-compose.ps1 on Windows with Docker Desktop and WSL2. The script pulls prebuilt images from ghcr.io and starts the backend, a Huey worker, the frontend and Qdrant. ### Which address do I open after starting CISO Assistant? The backend service in the provided docker-compose.yml sets CISO_ASSISTANT_URL to https://localhost:8443, and the healthcheck polls http://backend:8000/api/health/. The README does not document the login flow itself, so the first-run credentials are something to confirm from the docs site. ### Can I run CISO Assistant from the main branch in production? No. The README explicitly warns against using main branch code directly for production, describing it as the merge upstream that can have breaking changes during development, and says to use tags for stable versions or prebuilt images instead. ## Sources - [intuitem/ciso-assistant-community on GitHub](https://github.com/intuitem/ciso-assistant-community) - [Issues](https://github.com/intuitem/ciso-assistant-community/issues) - [Project website](https://intuitem.com) - [README](https://github.com/intuitem/ciso-assistant-community/blob/main/README.md) - [Releases](https://github.com/intuitem/ciso-assistant-community/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/intuitem-ciso-assistant-community