Compliance › Software

Build vs buy software for compliance: should you build your own GRC platform?

Build vs buy software for compliance is no longer a GDPR-only question. See what the tool must document across GDPR, NIS2, DORA and the AI Act, what each route costs over five years, and when building genuinely makes sense.

A road forking into a build path with a crane and a buy path with a finished platform, meeting again at one shared platform

A few years ago, the build vs buy software question in compliance was really a GDPR question. A record of processing, some data processing agreements and a breach log could live quite happily in a spreadsheet or a small in-house tool. That is no longer the picture. NIS2 now applies through national law in most member states, DORA has applied to the financial sector since 17 January 2025, the AI Act deadlines were moved this summer, and the Cyber Resilience Act has required manufacturers to report exploited vulnerabilities since 11 September 2026.

At the same time, building your own has never looked easier. With AI coding assistants and low-code platforms, one developer can have a working prototype in a week. The real question is what happens over the next five years.

This article gives you a basis for the decision. We separate the routes you can actually choose between, set out what a compliance tool has to document across frameworks, work through a fictional five-year cost example and are candid about when building is the better choice. We sell a GRC platform ourselves, so we rely on public sources for the numbers and say which ones.

The short answer: build vs buy software for compliance?

For most organisations with 50 to 1,000 employees, buying a GRC platform and building a few integrations around it is cheaper and less risky than building from scratch. The big cost of an in-house tool is not the first release. It is hosting, security and keeping up with regulatory change for as long as the system lives, and you carry all of it alone. Build if compliance is part of your core product, if you have requirements no vendor can meet, or if you already run a platform team with a secure development process inside your ISMS. Whichever route you take, software does not make you compliant. Your controls, your management body and your evidence do.

Three routes, not two

The debate is usually framed as build against buy. In practice organisations choose between three routes, and many end up with a mix. It helps to separate them before comparing prices, because each one fails in a different way.

Route	What it is	Who owns maintenance	Typical pitfall
Spreadsheets and documents	Excel, SharePoint or Teams with templates, folders and an annual plan	The compliance lead	No audit trail, duplicate entries across frameworks and reliance on one person
Custom compliance software	An in-house system built from scratch, on a low-code platform or with AI-generated code	Your IT team or an external development partner	Hosting, security and regulatory change become a permanent internal job
Bought GRC platform	Standard governance, risk and compliance software configured to your organisation	The vendor (platform) and you (content)	Features you do not use and dependence on a supplier
Hybrid	A bought platform at the core, with your own integrations and reports via API or a BI tool	Shared	Integrations need upkeep too, but they are small and well defined

A spreadsheet is not wrong by definition. For an organisation with few processing activities and no NIS2 obligations it can go a long way. We cover that choice in a separate comparison of GDPR in Excel or software. This article is about the next step: when the spreadsheet no longer copes and the choice is between developing a system yourself and buying one.

Four columns comparing spreadsheets, custom compliance software, a bought GRC platform and a hybrid by who owns maintenance and the typical pitfall

What compliance software has to do in 2026

The most underestimated part of any build project is the requirements specification. A compliance tool is not a document store. It has to show a supervisory authority or an auditor that you did what the rules require, and when. The table lists the frameworks a typical European organisation with 50+ employees has to deal with, and what the system must be able to evidence.

Framework	What the system must evidence	Legal source	Applies from
GDPR	Record of processing, processors and contracts, risk assessments, personal data breaches and the ability to demonstrate compliance	Art. 5(2), 24, 28(3), 30, 32 and 33(5)	25 May 2018
NIS2	Management approval of risk-management measures, the ten minimum measures, supply chain security and incident reporting (24 hours, 72 hours, one month)	Directive (EU) 2022/2555, Art. 20, 21(2) and 23, through national law	Transposition deadline 17 October 2024. National dates vary
DORA	Register of information on ICT third-party arrangements, classification and reporting of ICT incidents, and exit strategies	Regulation (EU) 2022/2554, Art. 17-19 and 28-30	17 January 2025 (financial entities)
AI Act	AI literacy, an inventory of AI systems, deployer obligations and fundamental rights impact assessments	Regulation (EU) 2024/1689, Art. 4, 26 and 27, as amended by Regulation (EU) 2026/1744	Art. 4 from 2 February 2025. Annex III high-risk from 2 December 2027
Cyber Resilience Act	Reporting of actively exploited vulnerabilities and severe incidents by manufacturers of products with digital elements	Regulation (EU) 2024/2847, Art. 14	11 September 2026 (reporting). Other obligations 11 December 2027
ISO/IEC 27001:2022	Risk assessment and treatment, Statement of Applicability, documented information, internal audit and management review	Clauses 6.1.2, 6.1.3, 7.5, 9.2 and 9.3 plus 93 Annex A controls	Voluntary. 2013 certificates expired on 31 October 2025

Two things stand out. The first is overlap. One annual review of an IT supplier can at once cover processor oversight under GDPR Art. 28, supply chain security under NIS2 Art. 21(2)(d), the DORA register under Art. 28 and ISO 27001 controls A.5.19 to A.5.22. That is the core of GRC: one control, many requirements. So an in-house system cannot simply store tasks. It has to link each task to several requirements in several frameworks and show status for each framework separately. That data model is harder to get right than it looks.

The second is that the list does not stand still. Our article on information security risk management across GDPR, NIS2, DORA and ISO 27001 goes deeper into the overlap.

The rules change while you build

Take the last 14 months alone. The Data Act began to apply on 12 September 2025, with new rules on switching between cloud and other data processing services. On 4 September 2025 the Court of Justice gave judgment in Case C-413/23 P (EDPS v SRB), refining when pseudonymised data count as personal data for a recipient. On 19 November 2025 the Commission proposed a Digital Omnibus that would amend the GDPR and create a single entry point for incident reporting. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and pushed back the AI Act's high-risk deadlines. And on 11 September 2026 CRA reporting went live through ENISA's Single Reporting Platform.

National law adds another layer. NIS2 is a directive, so each member state writes its own act, with its own authorities, registration duties and sometimes extra sector rules. In July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose it. A group operating in several countries needs a tool that can hold more than one national version of the same requirement, and keep up as the late adopters catch up.

Every one of these changes means new content, new fields or new deadlines in a compliance system. With a vendor, that work is shared across all customers. With custom compliance software, it lands on your desk.

Timeline from September 2025 to September 2026: C-413/23 P, Data Act, Digital Omnibus, NIS2 court referrals, Regulation 2026/1744 and CRA reporting

What building really costs

Most IT projects do not go badly wrong. That needs saying, because the build vs buy software debate is often argued with scare statistics. The problem is not the average. It is the tail: the minority of projects that overrun by a wide margin.

The largest study on the subject is Flyvbjerg, Budzier and colleagues, The Empirical Reality of IT Project Cost Overruns, published in the Journal of Management Information Systems in 2022. The Oxford-led team analysed 5,392 IT projects and found that cost overruns follow a power-law distribution. The median project came in on budget. Across the 4,677 projects with both an estimate and an actual cost, the mean actual cost was 1.8 times the estimate, because a minority of projects overran dramatically. The largest overrun in the dataset, the authors report, was a small workflow customisation project budgeted at USD 1,500 that ended up costing USD 425,000.

That last example is worth dwelling on, because a compliance tool is essentially workflows: tasks, approvals, reminders and evidence. McKinsey and the University of Oxford reported in 2012 that large IT projects above USD 15 million ran on average 45% over budget and 7% over time while delivering 56% less value than predicted, and that 17% went so badly they could threaten the existence of the company. Those figures concern large projects and are more than a decade old, so treat them as an illustration of tail risk, not as a forecast for an internal compliance tool.

The costs start when the system goes live

Custom compliance software carries a set of costs that rarely appear in the first estimate. The table shows who typically bears them.

Cost item	Build	Buy a GRC platform
First release	Development hours, requirements from the compliance team, testing	Configuration and import of existing documentation
Hosting, backup and monitoring	You	The vendor
Security patching and vulnerability handling	You, continuously and with no end date	The vendor
Access control, logging and change history	Must be built and maintained	Standard features you configure
New framework or changed rule	A new development project	A new or updated template you adapt
Key-person risk	High if one developer knows the code	Low for the platform, still real for the content
Subscription	None	Ongoing, usually per module or per user
The compliance work itself	You	You

The last row is there for honesty. No compliance software performs your risk assessment, supplier oversight or board reporting for you. It structures the work, reuses it across frameworks and makes it traceable. That is what you pay for, or what you build.

AI coding tools make the prototype cheap, not the operation

In 2026 it is realistic for a capable developer with an AI coding assistant to build a usable prototype of a task and evidence system in a few days. That changes the maths for the first release. It does not change the maths for the four years that follow. Code written quickly still has to be security tested, documented and maintained by someone who understands it. And the content, meaning which requirements the system covers and how they connect, does not come from the coding tool. It comes from your lawyers and security people.

Stacked bars for years 1 to 5 of building: first release is 33% of the five-year cost, operation, security and regulatory updates 61%

When the tool itself becomes a compliance object

This is the angle most build vs buy software articles miss. A compliance system holds personal data about staff, data subjects and supplier contacts, descriptions of your vulnerabilities and details of security incidents. It is one of the most sensitive systems you run. So it is itself caught by the rules it is meant to help you meet, and the obligations look different depending on whether you build or buy.

Requirement	If you build	If you buy
GDPR Art. 25 and 32	You must design data protection by design and by default and appropriate security into the system yourself	You must assess whether the vendor's measures are appropriate
GDPR Art. 28	Not relevant for your own system (but relevant for your hosting provider)	The vendor is a processor. You need a data processing agreement under Art. 28(3) and appropriate oversight
NIS2 Art. 21(2)(d) and (e)	Security in development and maintenance, including vulnerability handling	Supply chain security and assessment of the supplier
ISO 27001:2022 Annex A	A.8.25 to A.8.28 on secure development and coding must work in practice	A.5.19 to A.5.23 on suppliers and cloud services
DORA Art. 28-30 (financial entities)	Own operation, but hosting and underlying ICT services go in the register	The contract goes in the register and must contain the required clauses and an exit strategy
Exit and portability	You own the data and the code, and all of its technical debt	Secure export in a usable format. Data Act Art. 23-31 give customers of certain data processing services a right to switch, and switching charges are abolished from 12 January 2027

When you buy, the vendor has to be able to evidence its security. Ask for the data processing agreement, an independent assurance report such as ISAE 3000, ISAE 3402 or SOC 2, or an ISO 27001 certificate, the data location and sub-processors, and how you get your data out if you leave. The EDPB's Guidelines 07/2020 on the concepts of controller and processor set out what the controller must check. Our guide to the data processing agreement covers the contract itself.

When you build, the challenge is different. Your own development team then has to meet the same secure development standards you impose on your suppliers. Many organisations only discover at their first internal audit that the compliance tool is not inside the ISMS scope.

A worked example: five years of build vs buy software

Lakeside Water Services and Anna Berg are fictional. We invented them for this article, and they are neither a customer nor a case study.

Lakeside Water Services is a regional drinking water and waste water utility with 220 employees in an EU member state that has transposed NIS2. It is in scope of the national NIS2 act, processes personal data about customers and staff under the GDPR and uses ISO 27001:2022 as its security framework without being certified. Anna Berg is head of compliance and information security. Today she keeps the record of processing in Excel, supplier contracts in SharePoint and the annual plan in Outlook. The six-person IT team has proposed building an internal tool on the company's low-code platform.

Anna sets out both routes over five years. The hourly rates are our assumptions for the example, not market data: €115 an hour for an internal developer and €100 for a compliance professional, both fully loaded. The subscription uses .legal's list price as of September 2026 of €200 per module per month, excluding VAT.

Item	Build (5 years)	Buy a GRC platform (5 years)
Requirements / implementation	200 hours of compliance time: €20,000	150 hours of compliance time for set-up and import: €15,000
First release	900 developer hours incl. testing: €103,500	None
HR system integration	Included in the first release	80 developer hours via API: €9,200
Operation and further development	250 hours a year in years 2-5: €115,000	20 hours a year on the integration in years 2-5: €9,200
Hosting, backup and annual security test	€11,000 a year in years 2-5: €44,000	Included
Regulatory updates	80 hours of compliance time a year in years 2-5 to specify changes to the system: €32,000	New and updated templates are part of the subscription. Adapting your own content is excluded on both sides
Subscription	None	4 modules plus API (€135 a month) for 5 years: €56,100
Supplier oversight	Hosting provider only (excluded)	10 hours a year: €5,000
Total over 5 years	€314,500	€94,500

Anna then runs two sensitivity checks. If the first release ends up at 1.8 times the estimate, the mean in the Flyvbjerg study, the build route rises to about €397,000. If AI coding tools halve the development time for the first release, it falls to about €263,000. In neither case does building come close to buying, because operation, hosting and regulatory updates alone cost €191,000 over years 2 to 5.

She also notes the timing. The internal tool would not be ready for at least three quarters, whereas the platform could be used straight away. During that period the NIS2 evidence would still sit in spreadsheets.

The point is not that buying always wins. Had Lakeside had a platform team with spare capacity and an existing development process inside its ISMS, the marginal cost would be lower. And had the utility needed to feed compliance data straight into the control systems that run its treatment works, a hybrid with its own integration would be the natural choice. The example shows that the answer is decided by the years after the first release, not by the first release.

Cumulative five-year cost for a fictional utility: build €314,500 with a band of €263,000 to €397,000, buy €94,500

When does it make sense to build?

There are situations where custom compliance software is the right call. We see them less often than you might expect, but they exist. Tick the ones that apply to you.

☐ Compliance is part of your product. You are a bank with proprietary risk models or a RegTech firm, and the compliance logic is a competitive advantage.
☐ You have requirements no vendor covers. A sector-specific rulebook or workflow that standard platforms cannot be configured for.
☐ Data must not leave your environment. Classified information or a requirement to run in your own data centre that vendors cannot meet.
☐ You already have a platform team. A team with spare capacity and a development process that already meets ISO 27001 A.8.25 to A.8.28.
☐ You are very large. A group with many entities and an application portfolio where a compliance tool is one of several hundred internal systems.

If two or more apply, a thorough analysis of building is worthwhile. If none do, the real question is which GRC platform to choose and whether to build integrations alongside it. The hybrid is often the best of both: buy the core with registers, risk assessments, frameworks and task management, and build the few integrations and reports that are unique to you.

How to make the build vs buy software decision in six steps

Map frameworks and roles. Which frameworks apply to you today, and which will within three years? Are you a controller, a processor, an essential or important entity under NIS2, a financial entity under DORA, a deployer of AI?
Describe controls and overlap. List the controls you already run and which requirements each one satisfies. That shows how much reuse the system has to handle.
Write the system requirements. Change log, access control, reminders, export, reports for the board and auditors, integrations and languages. Separate must-haves from nice-to-haves.
Calculate five-year costs for both routes. Include operation, security and regulatory updates, and run a sensitivity check where the first release costs twice the estimate.
Assess the vendor as a supplier. Data processing agreement, independent assurance or certification, data location, exit and export format. For financial entities, the DORA contract requirements too.
Test on a limited scope. Take one framework or one department and run it through in practice before you commit. That applies to a prototype and to a bought platform alike.

For vendor selection in more depth, see our guide to buying compliance software and our article on GRC software.

Six steps for the build or buy decision: map frameworks, describe controls, write requirements, calculate five-year costs, assess vendor, test

What compliance software does not solve

A system fixes a structure problem. It does not fix a governance problem. Under NIS2 Art. 20, the management body must approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. No platform can do that on the board's behalf. The same goes for GDPR Art. 24, under which the controller must be able to demonstrate that processing complies with the Regulation.

Nor is a system better than the data inside it. An out-of-date record of processing is just as wrong in a platform as in a spreadsheet. The difference is that the platform can remind the owner to update it, show who changed what, and reuse the information in risk assessments and supplier oversight.

And some organisations need neither yet. With fewer than 50 employees, few processing activities and no NIS2 obligations, a well-kept spreadsheet with a fixed annual plan can be enough. What matters most is that someone owns it.

How .legal supports both buying and building

.legal is a GRC platform built for exactly the overlap this article describes. In our Frameworks module you link one control or task to the requirements it meets across several frameworks, such as the GDPR, NIS2, ISO/IEC 27001:2022, the Data Act and the CRA, and status updates in every framework once the task is done. Tasks sit in compliance task management with owners, deadlines and evidence.

Suppliers and processors are handled in vendor management, where the same supplier review can serve both GDPR and NIS2, and assets and risks live in the information security module. If you want to build parts yourself, the Public API gives access to legal entities, contracts and assets so you can connect the platform to your own systems. Reports and lists can be exported, so your data is not locked in.

The platform does not make you compliant, and it does not replace your lawyers and security people. It removes the duplicate work and the job of running a system, so they can spend their time on the work itself. See the pricing, start on the free plan, or book a demo to see how your own frameworks look in the platform.

Frequently Asked Questions About Compliance Software

What does build vs buy software mean in compliance?

It is the choice between developing your own compliance tool in-house and buying a ready-made GRC platform. Building gives you full control over features and data, but you carry development, hosting, security and regulatory updates for the life of the system. Buying shares those costs across the vendor's customers, but you depend on a supplier and accept its product roadmap. Many organisations end up with a hybrid.

What is the difference between compliance software and GRC software?

GRC stands for governance, risk and compliance. GRC software is the broader category, covering risk management, board reporting, policies and controls across several frameworks as well as evidence of regulatory compliance. The terms are often used interchangeably. The practical difference is whether a tool can link one control to requirements in several frameworks, or whether it was built for a single regime such as the GDPR.

How much does a GRC platform cost?

It depends on the number of modules, users and entities. Some vendors charge per user, others per module or through an enterprise agreement. At .legal each module costs €200 a month excluding VAT as of September 2026, with no lock-in and unlimited users. Always compare the five-year cost including implementation and internal hours, not just the subscription fee.

Is custom compliance software cheaper than buying?

Rarely over a five-year horizon. The first release may be cheap, especially with AI coding tools, but hosting, security patching, access control and keeping up with new rules continue for as long as the system runs. Research on thousands of IT projects also shows that a minority of projects overrun dramatically. Building tends to pay off only when you already have a platform team or genuinely unique requirements.

Is the vendor of a GRC platform a data processor?

Usually yes. The platform holds personal data about staff, contacts and data subjects, and the vendor processes it on your behalf. GDPR Art. 28(3) then requires a data processing agreement, and you must oversee the vendor appropriately. If you are in scope of NIS2 or DORA, the vendor also belongs in your supply chain or ICT third-party risk assessment.

How long does it take to implement compliance software?

A bought platform can be used straight away, but set-up and importing existing documentation typically takes a few weeks, depending on how much you already have. A custom tool needs requirements, development, testing and a security review before it can hold evidence an auditor will rely on. Expect months rather than weeks, even with modern development tools.

Can we build compliance software with AI coding tools?

You can build a prototype quickly, and that can be a good way to clarify requirements. The code still has to be security tested, documented and maintained, and the system must meet the secure development standards you expect from your own suppliers. AI tools also do not supply the content, meaning which requirements the system must cover and how they connect across frameworks.

What should a GRC platform do to support NIS2?

It should evidence management approval and oversight under NIS2 Art. 20, the ten minimum measures in Art. 21(2) including supply chain security, and the handling of significant incidents with the 24-hour, 72-hour and one-month steps in Art. 23. It helps if the same evidence can be reused for ISO 27001 and the GDPR instead of being recorded three times, and if it can reflect your national NIS2 act.

What happens to our data if we switch vendor?

That depends on the contract, so ask before you buy. Under GDPR Art. 28(3)(g), the processor must delete or return personal data when the service ends. The Data Act gives customers of certain data processing services a right to switch provider, and switching charges are no longer allowed from 12 January 2027. Make sure registers and reports can be exported in a format you can reuse.

Does compliance software make us compliant with GDPR and NIS2?

No. A system structures and evidences the work, but compliance depends on the measures you have actually put in place and on your management taking responsibility. NIS2 Art. 20 places accountability for risk management on the management body, and GDPR Art. 24 requires the controller to demonstrate compliance. Software makes it easier to prove what you do, but it does not do the work for you.