When things do not go as planned and problems start, whose responsibility is it?

Developing customised solutions presupposes that IT staff is aware of all the complications associated with the correct management of Consents, with the difficulties of collaboration  between Legal and ICT teams. Criticalities and risks that triple if development is delegated to an external provider.

The (real) risk is to underestimate the project, believing that the management of Consents is an easy process and that it is enough to tell the technicians (perhaps in the legal language) what needs to be done to have a result that complies with the Regulation. But in the end no one will really be able to certify the final product from a legal point of view, with the risk of witnessing a rebound of responsibility in the “moment of truth“, in the event of complaints or inspections, when it will finally become clear what was actually not correctly understood during the analysis and development phase.

GDPR is still fluid and the consent manager needs to be constantly updated (and certified!)

Even developing a GDPR-compliant product (of today), it will soon become obsolete when the company no longer invests in updating it. But even if they did update it (and it is very expensive), the end result would have to be re-certified by someone who takes responsibility for it. Employees change and so do providers: who in future will take legal responsibility for such a delicate system, designed and developed by others?
The real scenario is that this software, not being directly involved in the company’s business, will soon be forgotten and become another ‘legacy monolith’ in the company’s vast IT system, disowned by the legal profession, responsibility of the CIO, stuck all over the place and no one trusts it to be touched or removed (risking becoming the scapegoat for internal attacks and legal consequences).