Accountability should sit with the customer organisation, not the software provider. Privacy, legal, and business stakeholders need to own the implementation decision because they control how the banner is configured and interpreted. The vendor can provide guidance and support, but the final obligation to assess risk, approve changes, and maintain compliance remains internal.
Who owns the decision after a complaint is raised?
The decision to change cookie settings should be owned by the customer organisation because the complaint is usually asking for a change in policy, configuration, or legal interpretation. The provider may explain how the banner works, but it should not decide whether the settings are acceptable. That separation prevents a support ticket from becoming an outsourced compliance decision.
Why provider guidance is useful but not decisive
Vendors often know the technical limits of the cookie tool better than anyone else, so their input matters when assessing what can actually be changed. But a complaint is not just a technical question, it also touches consent language, jurisdiction, risk tolerance, and business impact. The organisation that collected the complaint must decide whether to preserve, alter, or remove a setting.
That ownership line matters because a provider can describe options, yet only the customer can weigh those options against its own privacy notices, legal obligations, and operating model. If the provider starts making the decision, the organisation loses control over a requirement that belongs to its own governance process.
What good internal accountability looks like
Good practice is to assign the complaint to a named internal owner with clear input from privacy, legal, security, and the business function that runs the site or product. The owner should be responsible for assessing whether the complaint reflects a genuine compliance issue, a wording problem, or a configuration mismatch.
- Confirm who can approve banner or consent changes before the complaint is closed.
- Keep a record of the complaint, the review outcome, and the reason for any decision not to change settings.
- Escalate quickly when the issue affects consent capture, regional requirements, or data-sharing behaviour.
Teams can also use established control guidance to structure that ownership. NIST SP 800-53 Rev 5 Security and Privacy Controls supports accountable access and privacy control decisions, while EU General Data Protection Regulation (GDPR) reinforces the need for internal responsibility around lawful processing and data protection by design. For organisations that need a broader governance lens, NIST Privacy Framework is a useful reference for assigning privacy-related decision ownership.
Risk and Threat Considerations
When cookie settings are changed without the customer organisation owning the decision, the main risk is control failure: the technical banner may be altered without a proper review of consent, legal basis, or regional obligations. That can create compliance exposure, inconsistent user experience, and weak evidence for why the setting was accepted or changed.
Failure mechanism: The organisation delegates a governance decision to a provider support channel, so the people with configuration access act without the people accountable for privacy and legal risk.
Impact: The result can be undocumented changes, inconsistent consent behaviour, and difficulty demonstrating that the complaint was handled by the right decision-maker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-1 — Access Control Policy and Procedures | Cookie-setting decisions need internal ownership and approval controls. |
| AU-2 — Event Logging | Complaint handling needs evidence of who changed consent settings and why. | |
| Recommendation — Assign and enforce internal approval responsibilities for consent-setting changes. Log consent-setting changes and retain change rationale for review. | ||
| ISO/IEC 27001:2022 | A.5.4 — Management responsibilities | The organisation must retain responsibility for governance decisions affecting compliance. |
| Recommendation — Define accountable owners for privacy-impacting configuration decisions. | ||
| GDPR | Article 5 — Principles relating to processing of personal data | Cookie decisions affect lawful, documented processing principles and accountability. |
| Article 24 — Responsibility of the controller | The controller remains accountable for the processing configuration decision. | |
| Recommendation — Align cookie configuration decisions with documented processing principles. Keep final consent-setting approval with the controller. | ||
Practitioner Guidance
What to verify: Verify that the customer organisation, not the provider, owns the final approval path for cookie configuration changes. If the provider is making the decision, the process is misaligned and should be corrected before the complaint is closed.
Decision rule: If the complaint concerns legality, consent validity, or regional configuration, route it through privacy and legal review first. If it only concerns implementation details, the provider can advise, but the internal owner still signs off on the outcome.
Practitioner takeaway: Treat the banner as a customer-controlled compliance setting, not a vendor-owned support issue; the provider informs the fix, but the organisation remains accountable for the decision.
