Protective Monitoring - Take that auditing and logging and alert people based on things happening. I.E. is it normal for your production app to try and call out to the internet? Frequency of actions of a user. Usage of privledged accounts. Rulesets will be app specific, but people should actually try to write these.

Rotation of secrets (or better yet, avoid static secrets) - Leavers shouldn't have your root db creds, because they used them once to setup the system. If someone hijacks a system, it's better they have a temporary token, rather than lots of credentials.

Zero trust network - You should run every system like it's connected to the internet. They should all have auth, auditing, monitoring and layered security. Just because something is on your internal network, doesn't make it secure.

Patch - Systems are like children, but many product teams are like deadbeat dad's you leave once the kid is born. Actually having a support policy that keeps systems up to date. This should be formalised in larger orgs.

Scan - CVEs are available for every popular language and OS for free. You should probably have SAST, DAST and Dependcy Scanning. Have this in your pipeline. Do it nightly against prod.

Use a framework - If it's on the web, you should probably be using a framework like Django, Rails or Symfony, or whatever seems sensible for the language you're using. Even your API responses should use your templating layer.

Basically, if you assume you're going to get hacked, which is a fair assumption, you want to:

a) Know that you've been hacked. Think about what a hacker is going to do once they breach your front door, or come in through a CI pipeline or a bad dependency.

b) Make recovery easy as possible (just patch the issue).

c) Limit what could be done with the hacked access. If your leaked access tokens only give you access to the hijacked app, deny and alert when someone trys to use it against something else.