How to Keep Your Systems Secure After Launch

Who This Guide Is For

This guide is for business owners and operations leads who are responsible for software that is live and handling real data. You do not need to be a security expert, but you need to ensure the right practices are in place so your systems remain secure as threats evolve and your team changes.

Before You Start

Your software should be deployed with a reasonable security baseline: encrypted connections, authentication on all access points, and no known vulnerabilities at launch. If you are not sure whether your system meets this baseline, start with a security assessment. This guide covers ongoing maintenance, not initial hardening.

Step 1: Keep Dependencies Updated

Every software application depends on libraries, frameworks, and packages written by other people. These dependencies regularly disclose security vulnerabilities, and patches are released to fix them. Your job is to apply those patches before the vulnerability is exploited.

Set a monthly schedule for dependency updates. Your development team should review available updates, assess which ones include security patches, and apply them in a staging environment before deploying to production. Security patches should be applied within a week of disclosure. Non-security updates can follow the monthly cadence.

Automated dependency scanning tools can flag vulnerable packages as soon as advisories are published. If your team is not using one, this is the highest-return security investment you can make.

Step 2: Review Access Quarterly

People join, change roles, and leave. Access permissions that were correct six months ago may not be correct today. A quarterly access review catches the drift.

For each system, review:

• Who has admin or elevated access? Is it still justified?
• Are there accounts for people who have left the organisation?
• Are there shared accounts? Eliminate them: shared accounts make audit trails meaningless.
• Are API keys and service credentials still active and necessary?

Revoke access the moment someone leaves the organisation, not during the next quarterly review. The quarterly review is the safety net, not the primary mechanism. Build access revocation into your offboarding process.

Step 3: Run Vulnerability Scans Regularly

Vulnerability scanning checks your application and infrastructure for known security issues. This includes outdated software, misconfigured servers, exposed services, and common web application vulnerabilities.

Run automated scans monthly. Review the results, prioritise findings by severity, and address critical and high-severity issues within two weeks. Medium-severity issues should be addressed within the month. Low-severity issues can be queued for the next maintenance cycle.

An annual penetration test by an independent security assessor provides a deeper evaluation than automated scanning. Penetration tests simulate real attacks and find issues that scanners miss, particularly logic flaws, authentication bypasses, and business-logic vulnerabilities.

Step 4: Monitor for Suspicious Activity

Security monitoring watches for unusual behaviour that may indicate a compromise or attempted attack. This does not require a security operations centre. Basic monitoring catches the majority of threats.

Monitor:

• Failed login attempts: a spike in failed logins from the same IP or targeting the same account indicates a brute-force attempt.
• Unusual access patterns: an account accessing data it does not normally touch, or accessing the system at unusual hours.
• Configuration changes: unexpected changes to user roles, permissions, or system settings.
• Data export volume: a sudden increase in data exports or API calls may indicate data exfiltration.

Set alerts for patterns that exceed normal baselines. The goal is not to watch every action in real time but to surface the anomalies that warrant investigation.

Step 5: Prepare an Incident Response Plan

A security incident will happen eventually. How quickly and effectively you respond determines the damage. Prepare before you need it.

Your incident response plan should cover:

1. Detection: how incidents are identified (monitoring alerts, user reports, third-party notification)
2. Containment: immediate steps to limit damage (isolate affected systems, revoke compromised credentials, disable compromised accounts)
3. Investigation: determine what happened, when, how, and what data was affected
4. Recovery: restore systems to normal operation, apply fixes that prevent recurrence
5. Communication: who needs to be informed (team, clients, regulators if applicable) and when

Name specific people for each step. Test the plan annually with a tabletop exercise: walk through a hypothetical scenario and verify everyone knows their role.

Common Mistakes

• Treating security as a one-time project. Security at launch is a baseline. Without ongoing maintenance, it degrades over time as new vulnerabilities are discovered and the team changes.
• No dependency updates. Unpatched dependencies are the most common attack vector for web applications. Monthly updates are the minimum.
• Shared accounts. When three people share one admin login, you cannot tell who did what. Eliminate shared accounts and give each person their own credentials.
• No incident response plan. Deciding how to respond during an incident wastes critical time. Plan in advance when you can think clearly.
• Over-permissioning for convenience. Giving everyone admin access to avoid support requests is trading a minor inconvenience for a significant security risk.

What Good Looks Like

A well-secured post-launch system looks like this: dependencies are updated monthly with security patches applied within a week. Access is reviewed quarterly with immediate revocation on departure. Vulnerability scans run monthly and findings are addressed by severity. Monitoring alerts on suspicious patterns. An incident response plan exists, is documented, and has been tested within the last year.

Next Steps

For WordPress-specific security maintenance, How to Maintain a WordPress Site Long-Term covers the platform-specific considerations. For access control implementation, How to Implement Role-Based Access Control covers the setup process. If you want this handled rather than managed in-house, Security Hardening is the relevant service, or get in touch to discuss ongoing security as part of a retainer. For related reading, browse the Operational Guides index.