Your outlined approach to listen for DELETE events unfortunately won't work out as it is triggered after the actual deletion has taken place. So the node is already gone when your code gets notified. Unfortunately, events and listeners/handlers won't help in this situation.
Depending on your use case probably the best solution will be based on permissions as mentioned by @KiranVedantam1992.
When it comes to permissions, it's always important to have a proper concept and a well designed content architecture that is aligned with the authorization concept. So please make sure to embed the required permissions into your concept.
That being said, you should be able to satisfy your requirement by defining an ACL of type DENY with the jcr:removeNode privilege for the according group.
Please also note: in general, it is recommended to built a hierarchy of groups to implement your authorization concept. It is a best practice to start with groups denying as much as possible/needed on to top level and only set ALLOW ACLs from there on. It can cause unexpected side effects if you mix allow and deny ACLs through your permission hierarchy. However, in some cases it may still be necessary to have few, well designed denys at some point in the hierarchy.