Why Integration Is Not Enough: The Case for a Shared Data Model

Integration syncs records between systems. A shared data model means there is only one record. That difference decides whether your compliance evidence survives an audit.

The sync is green, and the audit still fails.

Your integration dashboard says everything is fine. Each connector shows “last sync: 4 minutes ago.” But when an auditor asks you to prove multi-factor authentication was used on a client’s admin accounts on March 14, you end up spending hours pulling data from three systems and exporting it more than once.

This isn’t a flaw in your integration. Everything worked as planned: the connectors copied fields from one database to another on time. But they can’t make two systems agree on what a fact is, when it happened, or who can see it. Only a shared data model can do that. Without it, you just have a translation layer pretending to be one.

For years, MSP software vendors have said integration is the solution to tool sprawl. The usual advice is to buy the best PSA, the best GRC platform, connect them, and you’re done. But this hasn’t fixed the problem—people are still buying integrations. According to Salesforce’s MuleSoft 2026 Connectivity Benchmark, 95% of 1,050 IT leaders still face integration obstacles. Even after a decade of iPaaS, middleware, and connectors, these ongoing issues show that integration has real limits, not just a backlog.

If you’re a CTO considering compliance automation platforms, the key question is: how many data models are involved? The answer will affect your team’s work for years.

What a data model actually is

A data model defines the entities a system tracks, how they relate to each other, and the rules the database enforces. For example: client, ticket, control, evidence artifact, policy, time entry, and invoice. It also covers which entities can reference others and what the database will reject.

The rules are what matter most. A constraint is not just documentation; it’s a rule the database enforces every time someone writes data, even if the developer is new and hasn’t read the docs. In a single data model, an evidence record can’t point to a control that doesn’t exist because the database will block it.

Integration works like a translation contract between two data models. It maps fields from system A to system B, usually on a schedule and in one direction. This helps, but only for things both systems understand. For example, a PSA doesn’t know about control test results, and a GRC platform doesn’t track billable time against an SLA. The process just puts the data in a field that seems similar, so the meaning of that field changes depending on which system you view.

Integration answers, “Can these systems share data?” Architecture answers, “Is there only one version of this fact?” During an audit, only the second question matters.

Four things that break when systems share data instead of a model

These problems aren’t rare. They happen during normal operations and often go unnoticed until you need to look back and figure out what happened.

1. Identity: what counts as a client

Your PSA sees a client as a billing entity. Your GRC platform sees a client as an organization linked to a framework. Your RMM sees a client as a site. Since these are all different, syncing them means picking a join key, usually company name or email domain. Both can change and neither is unique.

If a client buys a competitor and wants one SOC 2 report for both but separate invoices, or if a healthcare group has two legal entities sharing IT and one HIPAA scope, your join key needs a manual exception. Someone has to keep that mapping table updated forever. Once client identity is only approximate, every number that depends on it is also approximate, including the compliance score you show the client.

2. Referential integrity: a foreign key versus a hope

Inside one database, an evidence record that points at ticket 48213 is protected by a foreign key. Delete that ticket and the database refuses, or cascades, depending on how you defined it. Either way, the outcome is defined.

When you use two databases, “48213” is just a string in a field. That ticket could be merged, renumbered, or deleted, and nothing stops it. The evidence record still shows 48213 and looks fine on the dashboard. You only discover the problem when an auditor tries to follow the reference and finds nothing.

3. Temporal fidelity: sync lag becomes an audit gap

Synced systems eventually become consistent, which is fine for dashboards but not for evidence. Evidence needs to show what happened at a specific moment.

Each synced event has at least two timestamps: when it happened in the source system and when it arrived in the destination. Which one ends up in the evidence record? Usually, it’s whatever the integration author picked, often without input from an auditor. If there’s a connector outage, you might have six hours with no data, then a backfill that fills the gap. No alert goes off because the queue clears, but now all those records have the same ingest timestamp. An auditor looking at that window will notice and ask questions.

4. Authorization: permission models do not compose

You block a technician from Client B in your PSA. Your GRC platform has its own roles and scopes, and both are set up right. But between them is a sync service account that can read and write everything in both systems.

So you have least privilege set up in both systems, but there’s a privileged account in the middle that isn’t covered by either permission model. It’s rarely reviewed and often uses a credential which hasn’t been changed since setup. Auditors will ask about that account, and they should.

Where the difference lands in practice:

Auditability is the hardest test of an architecture.

Most debates about architecture are just theory until something puts them to the test. Audits do that, which is why compliance is the best way to see if your stack is truly unified.

A SOC 2 Type II audit checks how well your controls work over three to twelve months. Auditors don’t just ask if a control is active today; they want to see all the dated records for that period and pick samples themselves. Integrated stacks struggle here. To produce a solid set of records, you have to join data from two databases with different retention rules, clocks, and client definitions. Teams spend weeks on this every audit cycle, and that effort doesn’t add up over time.

Auditors don’t care if your systems are integrated. They want you to provide the full set of records, and then they pick the samples themselves.

Regulations are moving this way too. NIST CSF 2.0, released in February 2024, added Govern as a sixth core function, encouraging organizations to concentrate on documented accountability and traceable oversight, not simply technical controls. In healthcare, the HHS Office for Civil Rights proposed changes to the HIPAA Security Rule in January 2025, but it’s still just a proposal. HHS expects final action in July 2027, so nothing is enforceable yet. It’s worth watching, but not planning for. Still, the focus on documented, ongoing controls matches what auditors already expect.

Getting your data wrong is expensive. IBM’s Cost of a Data Breach Report 2026 found the average breach costs $4.99 million, a record high and up 12% from last year. Organizations using AI and automation in security saved an average of $1.93 million compared to those that didn’t. But automation only helps if all the data is in one place. Separately, Gartner estimated in 2020 that poor data quality costs organizations $12.9 million a year on average. That number is old and covers all industries, so use it as a general guide, not a specific benchmark for MSPs.

Multi-tenancy is a data-model decision, not a feature.

If you manage compliance for multiple clients, this is where architecture becomes real and practical.

When multi-tenancy is added on top, it means filtering data in the application code. Every query must include the right WHERE clause, and every developer has to remember this for every endpoint, every time. It works until someone forgets once, and then you have a cross-tenant data leak to explain to clients and regulators.

Row-Level Security puts the rule in the database itself. This way, the rule stays with the data, not just in the mind of the next developer. It’s like a foreign key: the database enforces it, and the database doesn’t forget.

Even if both products are multi-tenant, an integrated stack can’t fully isolate tenants because each system defines boundaries differently, and someone has to keep a mapping table updated. Regentra enforces isolation at the query level using Row-Level Security and refreshes the session token every time you switch clients, logging each change. You can find more details on the MSP management pillar page. The key point is that it’s better to show isolation in action than just claim it.

Questions to ask a vendor who says “we integrate”

There are six questions. A vendor with a single data model can answer each one quickly. A vendor relying on integration will need to explain their roadmap instead.

1. Is there one client record, or two that reconcile? Ask to see the schema, not the architecture diagram.

2. If I delete a ticket that an evidence record references, what happens? “Nothing” is the wrong answer.

3. Which timestamp lands in an evidence record, event time or ingest time?

4. What happens to evidence generated while a connector is down, and how would I know it happened?

5. What permissions does the sync service account hold, and is that account in scope for your own SOC 2 report?

6. Where is tenant isolation enforced, in application code or in the database?

These aren’t trick questions. They’re the same things your auditor will ask in about eighteen months, just worded for procurement.

Where Regentra fits

Everything runs on one platform, one codebase, and one data model.

Regentra manages professional services automation, compliance management, and multi-tenant MSP governance all on one codebase and one data model. If there’s a compliance gap, it becomes a remediation ticket for the right client. The work done becomes evidence linked to every affected control, and tracked hours go straight into billing. This happens not because connectors move records between systems, but because there’s only one set of records.

The Common Control Framework uses the same approach for compliance standards. If you set up encryption at rest once, it applies to all nine supported standards: HIPAA, SOC 2, NIST CSF 2.0, ISO 27001:2022, CMMC 2.0, PCI DSS 4.0.1, GDPR, the FTC Safeguards Rule, and the proposed HIPAA 2026 update. You don’t have to document it separately for each. This is only possible when controls, evidence, and client records are all in one data model.

Sources

• IBM, Cost of a Data Breach Report 2026 — global average breach cost $4.99M (record, +12% year over year); $1.93M average saving for organizations making extensive use of AI and automation in security. ibm.com/reports/data-breach

• Salesforce / MuleSoft, 2026 Connectivity Benchmark Report — survey of 1,050 IT leaders; 95% report integration challenges. mulesoft.com/lp/reports/connectivity-benchmark

• NIST, Cybersecurity Framework 2.0, February 2024 — introduces Govern (GV) as a sixth core function.

• AICPA, SOC 2 Type II reporting — operating effectiveness tested across an observation period, commonly three to twelve months, with the auditor sampling from a population of dated artifacts.

• HHS Office for Civil Rights, HIPAA Security Rule Notice of Proposed Rulemaking (RIN 0945-AA22), Federal Register, 6 January 2025 — proposed, not finalized. Moved to the Unified Agenda long-term actions list with anticipated final action July 2027.

• Gartner (2020) — poor data quality costs organizations an estimated $12.9M per year on average. Widely cited, cross-industry; treat as directional.

Figures not attributed to a named source above are framed as estimates and are illustrative rather than measured.

Frequently asked questions

Related reading

• The hidden cost of running PSA and compliance in separate tools
• What is a unified PSA + compliance platform
• Understanding cross-framework control mapping

Next step: See how unified data works →

‍