Self-hosted GRC tools for SOC 2: CISO Assistant and eramba

CISO Assistant is an open-core GRC platform. The community code outside its top-level enterprise directory is licensed under AGPL-3.0-only, which means a team can read, run and modify that code under the terms of that license. The platform ships more than 200 frameworks, including SOC 2, and keeps risk assessments and risk registers, applied controls, evidence, remediation action plans and a third-party risk module. It also maps controls between frameworks automatically.

• Framework coverage: SOC 2 is one of more than 200 frameworks, so the same applied controls can be assessed against several frameworks at once.
• Risk and treatment: Risk assessments, risk registers and action plans sit next to the controls that treat them.
• Evidence tracking: Evidence is attached to applied controls so the auditor's requests can be traced back to a control record.
• Third-party risk: A third-party risk module is included in the platform description.
• License scope: Files inside the enterprise directory fall under the proprietary intuitem Commercial Software License and need a contract with intuitem.

Confirm with intuitem which features sit in the enterprise directory, because the README does not list them, before you rely on any specific capability.

eramba Community is free to use, but it is not open source. It is licensed under eramba limited's own terms, which since a June 2024 update forbid modifying, selling, licensing or otherwise distributing the software. eramba's own staff state that it should not be called open source because redistribution is not allowed. Community covers 4 of the 7 use cases that the vendor describes, and the rest sit in the paid Enterprise edition.

• License terms: Use is permitted, but modification and redistribution are not, which affects any internal fork or customization plan.
• Use case coverage: Community covers 4 of 7 use cases.
• Enterprise only: Awareness Programs, Automated Account Reviews and Online Assessments are paid features.
• Enterprise only, integration: Automation, REST APIs, reporting and notifications are also paid features.
• Cost driver: Ask the vendor for the Enterprise price and terms in writing, because the cost depends on the modules you need.

If your SOC 2 plan depends on automated account reviews or API-driven evidence collection, confirm those features in the edition you will actually run.

eramba's risk management module records asset, third-party and business risks and links each one to its treatment through internal controls, policies, exceptions or projects. Each internal control defines an audit methodology, success criteria, an evidence owner and a testing schedule. From those dates, eramba generates audit records for the current and next calendar year, which gives the security team a planned testing calendar that maps to the criteria an auditor will sample.

• Audit methodology: Each control states how it will be tested, so the test can be repeated the same way each cycle.
• Success criteria: A defined pass condition makes the outcome of each test explicit for the auditor.
• Evidence owner: Each control names the person responsible for producing the evidence.
• Testing schedule: Audit records for the current and next calendar year are generated from the schedule.
• Scope of the schedule: The calendar covers two calendar years, so a Type 2 observation period longer than that needs records maintained outside the tool.

Check how the schedule, owners and evidence attachments export into the package your auditor will request.

The better fit depends on who runs the GRC program and how much they need to change the tool. A security team that wants to read and modify a framework-rich platform, and can accept AGPL obligations, will look at the CISO Assistant core first. A team that wants a fixed, scheduled audit workflow with clear ownership of each control, and can work within the Community feature set, will look at eramba Community. Either choice may need a paid tier once you need the modules that sit outside the free edition.

• Modification needs: Teams planning changes to the source should weigh the AGPL terms of CISO Assistant against the no-modification rule in the eramba Community license.
• Feature needs: List the features your SOC 2 plan requires, then check each one against the edition you would run.
• Team size: Small teams often gain more from a scheduled audit workflow than from a large framework library.
• Total cost: Include support, hosting and any enterprise contract, since the free license is only part of the cost.
• Vendor questions: Ask each vendor which features sit in the paid edition and what the license allows.

Before you commit, run a short trial with one control and one piece of evidence to see whether the workflow fits your team.

Your organization owns the controls, the risk decisions and the evidence. A GRC tool records what you decide and what you can show, but it does not make those decisions for you. Management must accept each risk, approve each control design and answer for each deficiency, because the SOC 2 examination relies on management's own description and assertion of the system.

• Risk decisions: Leadership accepts, mitigates, transfers or avoids each risk in the register, and records the reasoning.
• Control ownership: Each applied control has a named owner who can explain how it operates and who performs it.
• Evidence owners: Individuals are assigned to produce specific records on a schedule, such as access reviews or change approvals.
• Tool access: Your administrators decide who can edit controls, close findings and export records, and they keep those permissions under review.
• Testing schedule: Your team sets the internal testing cadence that the tool uses to generate audit records.

Before the audit, confirm with your compliance lead that every control in the tool has a documented owner and that the owner can explain the control to the auditor without help from the implementation partner.

An implementation partner such as DeployOpen can install, configure and integrate a self-hosted GRC tool inside your own infrastructure, and can prepare the structure in which evidence is collected. That work is preparation. The partner does not decide which controls you need, does not accept risks on your behalf and does not issue a SOC 2 report or opinion.

• Installation and hosting: Deploying the tool in your cloud account, data center or private network, with backups and upgrades agreed in writing.
• Integration: Connecting the tool to identity, ticketing, source control and logging systems where the platform supports it, after confirming the specific integration with the vendor.
• Evidence structure: Setting up the control matrix, evidence folders and audit records so your owners know what to upload and when.
• Documentation: Writing configuration records and runbooks that explain how the tool is operated.
• Scope limits: Work is fixed in a written scope, so tasks such as writing your policies or running your risk workshops must be assigned explicitly.

Ask the partner to state in writing which tasks it performs and which remain with your staff, so that no one assumes a control is covered when it is not.

The CPA firm is the independent service auditor. It plans and performs the examination under the AICPA attestation standards, tests whether your controls were designed and, for a Type 2 report, operated effectively over a period, and then issues the report. Only the CPA firm can do this. Neither your team nor your implementation partner can substitute for it.

• Independent testing: The auditor selects samples and examines evidence itself, including evidence produced by the GRC tool.
• Report issuance: The auditor issues the opinion and the report, and decides whether any exceptions appear in it.
• Management representations: Your management signs a representation letter, which the auditor relies on, so your team must be able to stand behind every statement.
• Independence rules: An auditor generally cannot design the controls it later tests, so the scope of help from advisors must be agreed with the auditor before work starts.
• Engagement terms: The auditor's engagement letter sets the scope, timing and the evidence it expects.

Before you engage an implementation partner, ask your CPA firm which preparation tasks it considers acceptable and record that answer in writing.