When the CMP Goes Down: The Fallback That Keeps You Compliant

A consent management platform goes down on a Tuesday afternoon, and every site that depends on it has to decide what to do in the next ten minutes. The sites with a fallback keep collecting consent. The sites without one either stop collecting data or collect it without consent, and both are wrong in different ways.

The CMP is a single point of failure, and nobody treats it as one

A consent management platform is a third-party service, and third-party services go down. The CMP loads from a remote script, the consent configuration lives on the vendor's servers, and the banner the visitor sees is rendered by code the site does not control. When the vendor's infrastructure fails, the banner fails with it, and the site has to decide, in real time, what to do about the consent it can no longer collect.

The two wrong answers are both common. The site that defaults to allow loads the tracking scripts because the CMP is unreachable, and collects data without consent, which is the violation the banner exists to prevent. The site that defaults to block stops loading everything, including the analytics it needs to run the business, and loses the data it could have collected lawfully, because the consent mechanism is down, not the consent itself. Both are failures, and both come from the same root: the site treated the CMP as infrastructure, and infrastructure does not fail, until it does.

Google Consent Mode v2 has a built-in fallback, and it is the model for what a fallback should do. When the CMP is unavailable, the default consent state applies, and the site can set that default to denied. The tags still fire, but they fire in a restricted mode, and no personal data is sent until consent is granted. The Consent Mode post covers the denied state in detail: the tags that fire when the answer is no, and the audit that checks they stay quiet. The point here is the outage: the fallback is not a feature of the CMP. It is a configuration the site sets, and a site that has never set it has no fallback at all.

The fallback has three parts, and all three are local

First, a cached copy of the consent configuration. The banner's text, the purposes, the vendors, and the choices, stored on the site's own infrastructure, so the banner can render without reaching the vendor. A banner that cannot render without the vendor is a banner that disappears when the vendor does, and a site with no banner is a site with no consent mechanism at all.

Second, a default-deny rule that applies when the CMP cannot be reached. The rule is simple: if the CMP does not respond, no non-essential script loads, and no personal data is sent. The default has to be deny, not allow, because the consent was never obtained, and the absence of a CMP is not consent. A fallback that defaults to allow is not a fallback. It is a bypass, and it is the bypass that turns an outage into a violation.

Third, a stored consent record that survives the outage. The consent the user gave yesterday is still valid today, and it should be stored on the site's own infrastructure, not only on the vendor's servers. A site that can read its own consent records can keep applying them during an outage, and a site that cannot has to ask every visitor again, which is the failure the fallback exists to prevent. The consent records post is the companion check: the record is the evidence, and the evidence has to survive the vendor.

Test the outage before it happens

Take the CMP down in a staging environment, and see what the site does. Does the banner still render. Do the non-essential scripts stay blocked. Does the consent record still apply. If the answer to any of those is no, the fallback does not exist, and the next outage is the test, which is the worst time to discover it.

The test takes an afternoon, and it is the afternoon that decides whether an outage is a ten-minute incident or a regulatory event. A site with a fallback keeps collecting consent through the outage, keeps its data lawful, and keeps its business running. A site without one has to choose between collecting data without consent and collecting nothing at all, and both choices are wrong. Build the fallback, test it, and keep the records. The CMP will go down. The question is whether the site notices.

Frequently asked questions

What is a CMP fallback?

A fallback is a local, cached copy of the consent configuration, and a default-deny rule that applies when the CMP cannot be reached. The site keeps showing a banner, and it keeps refusing to load non-essential scripts until the user consents, even though the CMP is down.

Is a site still compliant when its CMP is down?

It depends on the fallback. A fallback that defaults to deny, and keeps the banner working from a cached copy, is compliant. A fallback that defaults to allow, and loads the tracking scripts because the CMP is unreachable, is not, because the consent was never obtained.

What does Google Consent Mode do when the CMP fails?

Google Consent Mode v2 has a built-in fallback: when the CMP is unavailable, the default consent state applies, and the site can set that default to denied. The tags still fire, but they fire in a restricted mode, and no personal data is sent until consent is granted.

Should I test the fallback before an outage?

Yes, and it is the test that matters most. A CMP that works is easy to test. A CMP that is down is the case the fallback exists for, and if the fallback has never been tested, it has never worked, because the first test is the outage itself.