I think you could count decline-events, but not track users who declined tracking. But I also think such information isn't useful for demonstrating compliance. Therefore, you should avoid storing extra data about people who do not give consent.
When consent is required for analytics.
The GDPR provides a general framework for processing personal data. The ePrivacy Directive (ePD) overrides this general framework when it comes to cookies and similar technologies related to accessing information on the end user's device. Per ePD, such access is only allowed when it is strictly necessary to provide the service explicitly requested by a user, otherwise consent is required. Thus, analytics cookies require consent and setting an analytics-declined cookie is strictly necessary.
But this consent requirement relates specifically to storage cookies, not to collecting analytics data. Thus, you might have a legitimate interest in collecting data with cookie-less analytics, which could involve counting cookie-consent decline events. Unfortunately, most analytics systems collect very broad categories of data and cannot be limited to a necessary subset. Even such limited analytics (unless they are truly strictly necessary for operating the site) should support an opt-out. I don't think you could legitimately gather analytics about such opt-out events.
GDPR audits.
Your motivation for collecting statistics about consent-decline events is to be prepared for a GDPR audit. This is probably not necessary, but it depends.
It might be useful to distinguish between internal/voluntary audits and data protection audits by the supervisory authority.
You might voluntarily review your compliance to convince stakeholders that you're compliant, and such voluntary audits might be part of the appropriate technical and organizational measures a data controller has implemented in accordance with Art 24, Art 25, and Art 32 GDPR.
You should collect any statistics you need for this purpose, e.g. to ensure that the opt-in rate looks realistic. But since you can set the parameters of this audit, it makes no sense to collect data “just in case”.
Under Art 58(1), your supervisory authority can audit your data processing and can compel you to provide any information it requires. This is similar to how a tax authority can compel you to produce business records for auditing purposes.
This is closely related with your general obligation to be able to demonstrate compliance with the GDPR (Art 5(2)). More specifically, the controller is required per Art 7(1) to be able to demonstrate that the data subjects have given valid consent, but does not prescribe how to demonstrate this.
How to demonstrate that valid consent was given.
For demonstrating that consent was given, there are no clear best practices. However, this topic is briefly discussed in EDPB guidelines 05/2020 on consent. They recommend that you retain records about the following:
- that a data subject in a given case has consented
- how consent was obtained
- when consent was obtained
- information provided to data subject at the time
- that the controller's workflow meets all relevant criteria for valid consent
Some of these are process-level concerns about how you ask for consent. For example, you might record video walkthroughs of your consent management solution to demonstrate how consent can be declined, given, and revoked. You should definitely keep a version history of the text and information that was displayed to users when they were asked for consent. I think you should also be able to explain in your front-end code how the result from your consent management solution is used to load relevant features (and that they aren't loaded before consent is given). If a feature or service is made conditional on consent, it might be good to have a short written analysis that consent is still freely given under the requirements of Art 7(4).
But other aspects relate to the individual data subject and the individual consent-giving event. Some consent management solutions send a small record about the consent to a backend server where it is stored with a timestamp, so that it can be later traced that and when consent was given. I've also seen consent management tools that show a timeline of events to the user (when consent was requested, and when consent for which purpose was given and revoked). I think such detailed insight into an pseudonymous individual's consent status is a very powerful way to demonstrate compliance.
What is not relevant here is information about data subjects who declined consent in the first place. Consent means opt-in. The default is that no consent is given. To demonstrate that consent was obtained in a valid manner, information about data subjects who didn't consent isn't necessary or useful.
So I expect that you would be fine in an audit without collecting such data. In fact, the lack of a clear purpose and necessity for collecting this data could be argued to be without legal basis and violate the GDPR's data minimization principle. And even when recording information about those data subjects who did consent, the EDPB guidelines remind us that this “should not in itself lead to excessive amounts of additional data processing”.
