First of all, the core functionality of all those third party compliance services is trivial and not worth paying for. Some of them, however, add things that may be valuable, but the core logic is very easy to reimplement.
Here is what you typically do:
That compliance pop up that you own and now have on the page. It should use something like a cookie to know whether to show or not (whether the client gave compliance or not). And that cookie should contain the info of the kind of consent the user gave.
Make a cookie variable in GTM that would grab your cookie value. You can also go the CJS route here. I prefer CJS since I often need to add logic there.
Make a trigger in GTM. the type of it would be custom event. The event name would be .* and regexp enabled like so:
Now this trigger will fire on every event. Not just DL events. Every event. Bear with me.
Oh, I spoiled it. The screenshot shows it. Well, yes, add the condition in which you reference the value of your cookie. So this trigger has to fire only when the cookie says tracking should not happen
As you could've guessed, this is a blocking trigger. We will now use it as a blocker in every tag that you want to comply to user consent, like so:
There we go. Keep in mind that this is only an example. It's not perfect. For example, it's much better to have "doesn't contain Allow" than "contain Block" because when the user consent is not given, there will be no cookie, therefore, it will not contain Block, therefore, you will be tracking things. A bit convoluted, but you get used to it.
Another point is that people often do something like leveled consent when they will ask a user about different kinds of tracking that a user can disable. Stuff like internal tracking, third party tracking, personalization, etc, etc. So you could build a more comprehensive logic, add more blocking triggers: some of which you would use for third party tracking, some for first-party and so on. I don't think it is very useful, but business often asks for this.