Only 41% of organization's have integrated their email infrastructure with their security and compliance stack, according to Exclaimer's research. The majority are running governance and operations in parallel, with no visibility across the join.
Technology due diligence should include a governance surface audit, not just a security review. And once a tool is in place, the standing question is: can we prove, today, that our governance posture is as strong as it was before we added this?
Every technology purchase gets evaluated on its merits. Cost, capability, integration complexity, security posture. The vendor gets asked for a penetration test report. The procurement team runs a risk assessment. The security team checks the data processing agreement.
What almost never gets evaluated is what happens to your governance posture when that tool integrates with the three others it will need to talk to.
That’s the question boards are not asking. And the longer they don’t ask it, the more expensive the answer becomes.
Governance risk is not additive. It multiplies.
Here’s the counterintuitive part. One tool is one governance problem. You have a single set of policies, a single audit trail, a single identity model to maintain, which is manageable.
Add a second tool with an integration to the first and you don’t have two governance problems. You have three governance surfaces: the first tool's internal governance, the second tool's internal governance, and the handoff between them.
That handoff is where your audit trail goes dark. It’s where identity controls don’t carry. It’s where the consistency your policy requires breaks down, because neither tool was designed to enforce it across the join.
Tools in your stack | Integration points | Governance surfaces |
|---|
1 | 0 | 1 |
2 | 1 | 3 |
3 | 3 | 7 |
4 | 6 | 13 |
10 | 45 | 91 |
Three integrated tools create seven governance surfaces. Ten tools with full integration create ninety-one. A typical enterprise environment with dozens of integrated tools has a governance surface count that almost no one has mapped. Most organizations couldn’t tell you today which of those surfaces is their weakest. That’s the multiplier problem.
Note on the maths: the integration point count follows the standard formula for connections in a fully connected network (n x (n-1) / 2). The governance surface count adds the tools themselves to the integration points. These are conservative figures. They assume each tool integrates with every other tool exactly once, with no additional middleware or API layers. Real enterprise environments are typically more complex.
What this looks like in a communications stack
Take a straightforward communications stack: an email platform, a CRM, an AI content tool, and a sending platform. Four tools. Each has its own governance model. None of them were designed to integrate at the governance level.
The email platform enforces disclaimer and signature policies within its own environment. The CRM manages contact data and interaction records under its own access controls. The AI content tool generates drafts with its own usage policies and, depending on the vendor, its own data retention rules. The sending platform distributes at scale with its own logging and deliverability controls.
Where do those governance models meet? They don’t. The integration points between these four tools, and there are at least six of them, are governed by nobody. Exclaimer's research across 4,000 IT professionals found that only 34% of organizations have integrated their email platform with their CRM at all, and only 41% have integrated their email infrastructure with their security and compliance stack. The majority are running these systems in parallel, which means the governance model on one side has no visibility into what the other is doing.
When something goes wrong in that stack, the question "where did this originate and who authorized it?" becomes very difficult to answer. Not because the tools failed individually, but because nobody governed the connections between them.
The objection, and why it doesn't hold
The reasonable pushback here is that each tool's own security and compliance controls should handle this. Vendors invest heavily in their internal governance. Why does the integration point create a new problem?
Because governance controls are designed within a tool's own logic, not across the handoff to another system. When data moves between tools, it moves through an integration layer that neither vendor built their governance model to cover. The audit trail that’s meticulous within the email platform doesn’t automatically extend into the CRM. The identity controls that work inside the AI content tool don’t carry through to the sending platform.
Your overall governance posture is only as strong as the weakest point in that stack. A highly governed email environment means very little if an AI assistant operating through an integration can generate and send communications without triggering any of the controls you’ve built. The governed layer gets bypassed by the ungoverned one. This is not a theoretical failure mode. It’s how most fragmented communications stacks are actually operating right now.
What the board should be asking
Technology due diligence has a governance gap at its center, and closing it requires two changes to how organizations approach technology decisions.
The first is a governance surface analysis at the point of purchase. Before any new tool is approved, the question should not only be "is this tool secure and compliant?" but "how many new governance surfaces does integrating this tool create, and who’s responsible for each one?" That analysis requires the question to be asked at all, which currently it is not.
The second is a standing review question for every tool already in place. The average cost of a data breach globally now stands at $4.88 million, according to IBM's Cost of a Data Breach Report 2024. The cost of asking the question first is considerably lower.
The boards that get ahead of this will not be the ones who bought the best individual tools. They will be the ones who understood that governance is a property of the system, not of its parts, and structured their technology decisions accordingly.
A practical starting point is what I would call the governance surface audit: before any new tool is approved, map the integration points it will create, name who’s responsible for governing each one, and confirm that the audit trail extends across every handoff. For tools already in place, the standing question is simple: can we prove, today, that our governance posture is as strong as it was before we added this? If the answer is no, or we do not know, that is the governance surface that needs attention first.
Exclaimer helps organizations centralize and govern their email communications at scale. Exclaimer serves over 80,000 organizations globally, including businesses in highly regulated industries. Read more about communications governance for IT teams or explore the Exclaimer partner programme for MSPs and resellers.
Paul Hammond
Chief Product and Technology Officer
Paul Hammond has spent 30 years building and leading product and engineering teams across consumer and enterprise software, at companies ranging from early-stage startups to some of the most recognised names in technology.
He spent 14 years at Microsoft, most of it on Skype, where he led engineering for the People Portfolio. After Microsoft, he ran B2C seller experiences at eBay, led engineering at Zoopla through a period of significant platform transformation, and served as CTO at Native Instruments before joining Exclaimer.
At Exclaimer, Paul leads product and technology as Chief Product and Technology Officer. His focus is on what sits beneath the email signature product: the rules and policy engine that could govern business communications at scale, and what it means to build a governance platform for an AI-accelerated world.
