How do you secure business critical applications?

To secure business critical applications, rank them by what an outage or breach would cost, then match controls to that rank: verified code, tight access, fast patching, monitored logs and tested recovery. The most critical systems get the strictest requirements and the most frequent proof that those requirements still hold.

Which applications count as business critical?

Ask one question per application: if this stopped for a day, or leaked its data, what would happen? Payroll, order intake, the customer database and the identity provider usually land at the top. A marketing microsite usually does not.

Write the answer down with an owner's name. Without a ranking, security work spreads evenly, and evenly spread effort under-protects the few systems that matter most.

What standard can you measure against?

The OWASP Application Security Verification Standard, ASVS, gives you a testable list. It describes itself as a basis for testing a web application's technical security controls and a list of requirements for secure development. The current stable version at the time of writing is 5.0.0. Its levels let you ask for more rigor where risk is higher, which fits the ranking above: a critical application gets the deeper verification level, a low-risk one gets the basic level.

For the organizational side, NIST's Cybersecurity Framework 2.0 organizes outcomes under Govern, Identify, Protect, Detect, Respond and Recover. For a critical application, the last two are often neglected, so check them first.

What does CISA expect for the basics?

CISA's Cross-Sector Cybersecurity Performance Goals are a short list of high-impact practices meant for organizations of all sizes. Version 2.0 aligns to CSF 2.0 and adds goals on governance and oversight, risks from managed service providers, least privilege and incident communication. They are voluntary, but they are a sensible floor: if a critical application does not meet them, fix that before adding anything sophisticated.

What can go wrong without the basics?

Constructed example. An order system runs on an old framework version because a customization breaks on upgrade. It sits behind a login that does not require a second factor, and its database backup lives on a server in the same network. A single exposed vulnerability gives an attacker the app, the data and the backup in one go. None of that needs an advanced attack. It needs three missed basics.

How do you protect recovery?

CISA's ransomware guidance says to maintain offline, encrypted backups of critical data and to test their availability and integrity in a disaster recovery scenario, because many ransomware variants try to find and delete or encrypt accessible backups. It also recommends keeping source code or executables with offline backups, and keeping infrastructure as code templates version controlled and backed up offline so cloud resources can be redeployed quickly.

The detail to copy: test the restore. A backup nobody has restored is a hope.

How should you review the result?

Once a quarter, ask each application owner three questions: what changed, what failed, and what would we do differently if it went down tomorrow. Keep the answers in one short document per application. Over a year, that record shows which controls are working and which are only on paper, and it gives auditors and executives something concrete to read. It also makes handover easier when an owner changes teams.

Treat the review as a trigger for action, not a report. If an owner says the last restore test was two years ago, schedule one this month. If the dependency list has grown and nobody has checked it, run a scan and fix the reachable findings first.

How to check or apply this

1. List critical applications, rank them by business impact and name an owner for each.
2. Pick a verification level from ASVS for each rank, and test against it.
3. Require multifactor authentication and least-privilege roles on every critical application and its admin paths.
4. Track the dependencies and runtime of each one, and patch known exploitable issues first.
5. Send application and authentication logs somewhere the application's own admins cannot erase.
6. Keep an offline backup, and run a timed restore at least once a year.
7. Write an incident plan that names who decides to take the application offline.

Quick check

Sources

• OWASP Application Security Verification Standard
• NIST Cybersecurity Framework
• CISA Cross-Sector Cybersecurity Performance Goals
• CISA #StopRansomware Guide

Last reviewed: 18 October 2026.