How to Keep Your Software Secure After Launch

This guide is for anyone responsible for a piece of business software now that it is live, and trying to keep it from becoming a security problem six months in. By the end you will know the operational rhythms that matter: patching, access reviews, dependency upgrades, monitoring, incident drills, and how to set them up so that security is something the business does routinely rather than rediscovers in a crisis.

Who This Guide Is For

Operations leads, IT managers, and technical owners running custom software in production. That might be a client portal, an internal tool, an e-commerce store, or a SaaS product. You are not building security from scratch. The application was built with security in mind. You are running the ongoing operational discipline that keeps it secure as the world around it changes.

Before You Start

You should have an inventory of what software you own, what infrastructure it runs on, and what data it holds. If you do not, the first task is producing one. Security operations on an undocumented portfolio is guesswork. You cannot patch what you do not know exists.

You should also know who is responsible for each system. “Whoever was on the original build” does not survive turnover. Every system needs a named operational owner with the authority and the budget to act.

Patching and Dependency Upgrades

The single most common cause of security incidents in production software is unpatched dependencies. The framework had a security advisory six months ago. Nobody applied it. An automated scanner found the vulnerability, and the system is now in the news.

The discipline that prevents this is unglamorous: a monthly review of dependencies against known vulnerabilities, with patches applied promptly. Tools like GitHub’s Dependabot, Snyk, or npm audit surface the issues automatically. The work is mostly judgment about which advisories are genuine risks to your application, which are theoretical, and which require immediate action.

For most business applications, a reasonable rhythm is critical security patches applied within 48 hours, high-severity patches within two weeks, and medium and low within the next monthly patching window. Major version upgrades (Laravel 11 to 12, React 17 to 18) are separate work and need their own scheduling, usually one major upgrade per significant dependency per year.

The biggest mistake is to let dependencies drift. A codebase that has not been touched for 18 months is running on a library set with 200 disclosed vulnerabilities. Getting back to current at that point is weeks of work. Staying current month-to-month is hours.

Access Reviews

Permissions tend to be granted generously and revoked rarely. Six months in, every system has accumulated users who should no longer have access: contractors who finished their engagement, employees who changed roles, accounts created for one-off purposes that nobody remembered to disable.

The fix is a quarterly access review. For each system, list every account, identify whose it is, confirm they still need that level of access, and revoke or downgrade anything stale. This includes both end-user accounts in the application itself and operational accounts in the hosting provider, the database, the deploy pipeline, and the third-party services.

Here is a real example. A client’s quarterly review of an internal system surfaced 23 active accounts that should not have existed: 7 ex-employees, 4 contractors from a project two years prior, 6 personal accounts on the development team’s hosting that had been left enabled, and 6 service accounts whose original purpose nobody could remember. None had been used recently, but all were live, including some with administrative privileges. Cleanup took 90 minutes. The risk surface dropped substantially.

Include offboarding in the access review process explicitly. When someone leaves the business, every system they had access to needs its credentials revoked the same day. A checklist of every system that an employee in role X has access to is a useful artefact. It makes offboarding repeatable rather than depending on memory.

Monitoring and Alerting

A security incident in progress is much cheaper to handle than one that has been running for three weeks unnoticed. The difference is monitoring.

The categories that matter:

• Authentication anomalies: failed login spikes, logins from unusual locations, password reset spikes
• Application errors: a sudden change in error rate can indicate exploitation attempts
• Database queries: unusual query patterns, large data exports, queries running for orders of magnitude longer than expected
• Outbound traffic: data leaving the system to destinations it normally does not communicate with
• Resource consumption: CPU or memory spikes that do not match user activity

Each of these has tooling. Application Performance Monitoring tools (Sentry, New Relic, Datadog) cover errors and resource consumption. Authentication systems usually have their own audit logs and anomaly detection. Cloud providers expose network flow logs. For software that exposes endpoints to the outside world, how to secure an API covers the request-level controls that sit underneath this monitoring layer.

The discipline is to route alerts to a channel that a human actually watches. An alert that fires into an inbox nobody checks is no better than no alert. The cost of an effective alerting setup is one to two days of work plus the ongoing tuning to keep false positives below the threshold where the team stops paying attention. Tuning is critical, because alert fatigue is the most common failure mode of monitoring.

Backups and Recovery Testing

Backups exist on almost every system. They restore on far fewer. The discipline is to test that backups actually work, before you need them in a crisis.

A reasonable cadence: backups are taken automatically every day, backup integrity is verified weekly (the file exists, the size looks right), and a full restore is tested quarterly. The quarterly restore is the one most teams skip, because it takes time and the team is busy. It is also the one that reveals the problems before they matter. If a backup does not restore, you do not have a backup.

The restore test should include the data, the configuration, and the third-party connections. A database restore that comes back with empty third-party API keys has not actually recovered, because the application cannot function. Document the full restore procedure as a runbook, test the runbook, and update it when anything changes.

Secrets Management

Production credentials such as database passwords, API keys, and encryption keys live somewhere. Best case, they live in a secrets management service (AWS Secrets Manager, HashiCorp Vault, Doppler) with access controlled and audited. Common case, they live in environment variables, with copies in developers’ shells and old config files. Worst case, they live in committed Git history.

The hygiene that matters: secrets are not in source code, ever. They are not in chat tools, ever. They are in a secrets management service with named human access. The access is logged and reviewed, and rotation happens on a schedule, quarterly for routine secrets and immediately for any suspected exposure.

When a secret is exposed, whether committed to Git, posted in a chat, or included in an email, the response is to rotate it immediately. Not “we should rotate it sometime”; rotate it within the hour. The cost of rotation is small. The cost of exploitation can be enormous. Treat exposure as a real incident, even when the exposure was internal-only.

Incident Drills

Security incidents are stressful and rare, which is a bad combination for clear thinking. The fix is to practice.

A drill is a tabletop exercise. The team gathers, walks through a hypothetical incident, and answers questions in real time. “We have just received a notification that a customer’s data appeared on a paste site. What do we do in the next 60 minutes?” The team works through the response, identifies the gaps in the playbook, and updates the playbook accordingly.

Drills do not need to be elaborate. An hour quarterly, with the operational team and a couple of senior leaders, is usually enough. The point is not to rehearse the perfect response. It is to surface the gaps in the existing process before they get discovered during a real incident. Common gaps surfaced by drills: nobody knows who can authorise customer notification, nobody knows where the backups are restored to during recovery, nobody has the legal team’s after-hours number.

For more on operational incident response specifically, How to Handle Software Incidents covers the broader operational discipline.

Common Mistakes

• Treating launch as the end of security work. The build’s security posture is the starting point. The ongoing operational discipline is what keeps it secure.
• Letting dependencies drift. Eighteen months without a patching cadence equals weeks of catch-up work plus a real risk window where vulnerabilities accumulate.
• No quarterly access review. Permissions creep upward and stay there. The risk surface grows quietly.
• Alert fatigue. Too many alerts, the team stops paying attention, real alerts get missed. Tune aggressively.
• Untested backups. Backups are not backups until you have restored from them. Test quarterly.
• Secrets in source code. Once committed to Git, a secret is effectively public until rotated. Treat rotation as urgent.
• No incident drill. When the real incident happens, the team is improvising. Drills make the response routine, even when the scenario is novel.

What Good Looks Like

Software that is being kept secure after launch has a monthly patching cadence with automated dependency scanning, a quarterly access review across both application users and operational accounts, monitoring that routes meaningful alerts to a real channel watched by a real human, weekly backup verification with quarterly restore tests, secrets in a managed secrets service with logged access and scheduled rotation, and a quarterly incident drill that exercises the playbook. The discipline is unglamorous but routine, and it is what separates security held as an ongoing posture from security suffered as a series of crises.

Next Steps

If you have not yet established the operational rhythm for the system overall, How to Run a Software Review Quarterly covers the broader review structure. If you are managing the relationship with the development partner that supports the system, How to Manage Software Vendor Relationships is the right read. For ongoing security support as part of a structured engagement, see Software Support Retainers, and the full set of operational guides covers the rest of the post-launch routine.