Insights · 12 min read
What a compliance management system contains, the modules it needs, whether to build or buy, and what a custom build costs. For founders and compliance leads.
By GGP Editorial
A compliance management system is the software layer that holds a company's regulatory obligations in one place: its policies, its controls, the evidence those controls work, and the people accountable for each. If you run a business in a regulated market, you already do all of this by hand. Policies sit in shared drives, controls live in someone's head, evidence gets assembled the week before an audit, and the whole thing falls apart the moment the person who "just knew" leaves.
Companies come to this decision for a few predictable reasons. A customer contract now requires SOC 2 before they will sign. A new market adds data protection rules they have to meet to keep selling there. A regulator sends a notice and asks for proof the business can produce on demand. When any of that happens, the spreadsheet approach stops scaling and you face a choice: buy a GRC platform or build a system that matches how your company actually operates.
This guide covers what the software contains, when building beats buying, what it costs, and where these projects stall. It is written for founders and for the compliance or engineering leads who have to make the call, not for developers weighing frameworks.
People use "compliance management system" to mean a few overlapping things, so it helps to pin down the core. The system does four jobs.
First, it records obligations. Every regulation, standard, contract clause, and internal policy that applies to the business goes in as a structured record, with an owner and a review date.
Second, it maps controls to those obligations. A control is a specific action the company takes to meet an obligation, like logging access to production data or reviewing vendor security every year. The system ties each control to the rule it satisfies, so you can prove coverage instead of asserting it.
Third, it collects evidence. For each control, the system gathers proof that it ran: screenshots, exports, attestations, test results, meeting notes. The value is in making that collection continuous rather than annual.
Fourth, it reports. Auditors, customers, and your own board want different views of the same data. The system produces those views without a manual copy-paste marathon.
A lot of the confusion around these systems comes from the fact that compliance work is boring and mostly invisible until something goes wrong. The software's real job is to make that boring work cheap to repeat.
The module list below reflects what gets used across the financial, property, and enterprise systems we build. Not every company needs every module, and the order you build them in matters more than the list itself.
| Module | What it does | You need it when |
|---|---|---|
| Policy management | Stores policies with version history, owners, and an approval workflow | You have more than a handful of policies that change |
| Obligations register | Central list of the regulations, standards, and contract terms that apply | You report to more than one framework |
| Control mapping | Links each control to the obligations it satisfies | Auditors ask you to show coverage |
| Evidence collection | Collects and stores proof that each control ran, with expiry dates | Audits happen yearly or more often |
| Risk register | Logs risks, their likelihood and impact, and who owns mitigation | You do any kind of risk assessment |
| Incident management | Tracks incidents, response steps, and post-incident actions | Breaches or near-misses need a process |
| Vendor and third-party risk | Tracks the compliance posture of suppliers and tools you rely on | You share data with vendors or use subprocessors |
| Access reviews | Periodic sign-off that only the right people hold access | You hold SOC 2, ISO 27001, or similar |
| Audit management | Schedules audits, tracks requests, and packages evidence | You go through external audits |
| Reporting and dashboards | Status views for leadership, customers, and auditors | Several stakeholders ask for status |
Two modules matter more than they look on paper. Evidence collection is where the yearly audit panic gets created or removed. Access reviews are where certification frameworks like SOC 2 and ISO 27001 tend to fail, because "who still has access to what" drifts quietly between reviews.
There are solid off-the-shelf products in this space. Vanta, Drata, Secureframe, OneTrust, and the larger GRC suites from ServiceNow and SAP all do parts of this well, especially for startups chasing SOC 2 or ISO 27001 quickly. If your needs fit a standard framework and you can adapt your process to the tool, buying is usually the right call and the cheaper one in year one.
You build when one of these is true.
Your compliance is not a standard framework. A lender with obligations across Hong Kong, the US, and A-share markets, or a property operator with local licensing rules, does not fit neatly into a SOC 2 template. Off-the-shelf tools get awkward fast when your controls reference local regulators rather than AICPA criteria.
Your compliance touches systems you already run. If evidence lives in an internal ERP, a proprietary trading system, or a custom payment flow, the integration cost of a SaaS platform can approach the cost of building something that reads those systems directly. We have seen this on financial and property management projects, where the compliance layer has to talk to code the company already owns.
You want to own the workflow. Regulated companies often have a specific approval path, evidence format, or escalation rule that no vendor tool will change for them. When the process is the differentiator or the audit is unusually strict, owning the software matters.
The middle path is common too: buy a lightweight GRC tool for the certificate, and build a small internal system for the parts that are specific to you. The decision is less build vs buy than deciding which 20 percent is worth owning.
Cost here follows team size, months of effort, and the number of integrations rather than a fixed price tag. A focused system that tracks obligations, controls, evidence, and access reviews for one framework typically lands in the $40,000 to $90,000 range. A broader system that adds risk, incident, and vendor management, dashboards, and integrations with several internal tools runs $120,000 to $300,000 or more. These are engineering estimates for custom builds, not vendor list prices, and they move with your specific scope.
The drivers that actually change the number:
Number of integrations. Every system you connect, an ERP, an HR tool, a payment gateway, a directory service, adds data mapping, authentication work, and testing. This is usually the biggest line item people underestimate.
Number of frameworks. One framework is a mapping exercise. Three frameworks that partially overlap, where you have to show the same control satisfying different rules, is a data modeling problem on top of it.
Evidence automation. Manual evidence is cheap to build but expensive to run. If you want the system to pull evidence from source systems automatically, that is more upfront engineering and a far lower annual cost.
Who uses it. A system for two compliance people is different from one that every department head logs into for attestations, which needs roles, notifications, and a decent interface.
Regulatory specifics. If your industry has rules about data residency, encryption, or audit logs, those add architecture requirements and testing. Financial services carry the heaviest version of this, because KYC and anti-money-laundering obligations shape how the system stores and links customer data.
A useful way to think about it is to split the build into an MVP that removes your biggest current pain, often evidence collection, and a second phase that adds the wider modules. Most teams over-scope the first phase.
A focused first version usually takes 10 to 14 weeks with a small dedicated team: a product-minded engineer, one or two backend developers, and a frontend developer, with QA and a project lead shared across the team. A broader system with several integrations and more modules runs 4 to 6 months. These timelines assume a fixed scope; they stretch when the scope keeps growing mid-build, which is the most common reason compliance projects run late.
Phase one, weeks 1 to 3, is definition. You inventory the obligations, map the controls, and lock the data model. This part feels like nothing is happening but it decides everything after it.
Phase two, weeks 3 to 8, is the core build: obligations, controls, evidence, and the access review workflow.
Phase three, weeks 8 to 12, is integrations, reporting, and hardening. The audit log, role model, and export formats get finished here because auditors will actually inspect them.
Phase four is handover: documentation, training, and a dry-run audit where the team assembles a sample evidence pack end to end.
The parts that get missed are almost never the core screens. They are the connections to systems that already exist.
Identity and directory. Access reviews need the source of truth for who has access to what. If that data sits in Okta, Microsoft Entra, or a directory service, the system has to read it. If it sits in a spreadsheet, the review is only as good as the spreadsheet.
Email and calendar. Attestations and review reminders only work if people actually respond, which means the system has to nudge them where they already work.
Storage and evidence. Evidence has to live somewhere durable and versioned. Tying this to your existing storage instead of inventing a new silo saves a lot of pain.
The internal systems you already built. A compliance layer that cannot see the trading system, the ERP, or the payment flow it is meant to police is a dashboard with no data behind it. When those systems are older, modernizing them enough to expose clean data is often the quiet prerequisite for the whole project.
The sponsor has to be someone with authority to change process, not just the compliance lead. A compliance management system that gets built but never changes how people actually work is a reporting tool, and reporting tools do not pass audits.
The compliance lead owns the content: what the obligations are, what the controls say, what good evidence looks like. The engineering team owns the data model and integrations. The sponsor owns the decisions where those two conflict, which happens more than people expect when a control is technically awkward to implement.
One practical rule: agree on the audit log and the export format before the first screen is built. Auditors read those, and retrofitting them later costs more than getting them right early.
How is a compliance management system different from a GRC platform?
GRC platforms are the commercial products that package governance, risk, and compliance together. A compliance management system can be a GRC platform you buy, or a custom system you build that focuses on the compliance slice. The terms overlap; the difference is whether you adapt to the tool or the tool adapts to you.
Do I need one of these to pass SOC 2 or ISO 27001?
No. Plenty of companies pass with spreadsheets and shared drives, especially early. The system becomes worth it when the audit happens yearly, the scope grows, or a customer demands evidence on a tight deadline and you want that to stop being a fire drill.
Can I build it in-house?
If you have engineers who are idle, maybe. Most teams are not idle, and compliance work has a habit of being deprioritized in favor of product features. A dedicated build team, whether you hire one or outsource it, is usually faster.
How much does it cost to maintain?
Figure 15 to 20 percent of the build cost per year for hosting and fixes, plus keeping integrations current, plus the ongoing time of the compliance lead who keeps the content accurate. Evidence automation pushes the operating cost down over time.
What should the first version include?
Obligations, controls, evidence, and access reviews. Skip risk and incident management until those four are working, unless a framework you must meet requires them from day one.
If you are weighing this build, the useful first step is not a line of code. It is a one-page inventory of your obligations, your controls, and where the evidence for each currently lives. That document is the scope, and it will tell you whether you are a build or a buy faster than any feature list will.
GlobeSoft has built financial, property, and internal business systems for clients across Brazil, South Africa, Singapore, and the US, and we routinely add the compliance and audit layer on top of systems a company already runs. If you want to talk through scope, modules, and what a build would cost, tell us about the obligations you are trying to cover.
Tell us what you are building and where you are today. We typically reply within 24 hours.
