A football stadium can pass every inspection before opening day.
The gates work. Restricted areas are secured. CCTV is operational. Staff have the right access badges, emergency procedures have been tested, and the venue meets the rules required to host a major match.
Now imagine the same stadium eight months into the season.
Temporary contractors have come and gone. New hospitality areas have opened. Access badges have been issued for events that finished months ago. Another camera system has been installed. A new ticketing partner receives customer information. A storage room has become a media workspace, while league and safety requirements have been updated during the season.
The stadium may still look exactly as it did on opening day.
But nobody responsible for running it would argue that passing the first inspection means there is nothing left to check.
Production applications work the same way.
An application can launch with strong security controls, carefully designed privacy practices and a clean compliance assessment. Then features are added, permissions expand, vendors change, data moves to new locations, dependencies age and requirements evolve.
The application is still running, but the conditions under which it was originally reviewed no longer exist.
That is why security, privacy and compliance belong inside application maintenance rather than being treated as launch activities.
OWASP's current Top 10:2025 includes risks such as Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Authentication Failures and Security Logging & Alerting Failures—several of which can emerge or deteriorate as a live application changes.
Privacy can drift just as easily. Under the EU GDPR, principles such as purpose limitation, data minimisation, storage limitation and appropriate security apply to the way personal information is actually processed, not simply to the design that existed when the application launched.
For Levelworks, this is primarily where the Secure and Compliant dimensions of App Health meet ongoing application maintenance. Other aspects—particularly Current & Updated, Observable, Tested, Version Controlled, Seamlessly Updatable and Well Documented—often determine whether security and compliance controls can remain effective as the product evolves.
The following checklist is designed around that reality.
Before checking controls, make sure you understand the current system.
Applications accumulate components gradually: another API, a background processor, a cloud service, a new authentication provider, a temporary integration that becomes permanent.
Documentation does not always keep up.
Maintain a practical inventory covering important:
The inventory should help answer operational questions.
If a security advisory affects a framework, can you tell whether production uses the vulnerable version?
If somebody asks where customer documents are stored, can you identify every meaningful copy?
If a compliance review asks which vendors receive personal information, can you produce a reliable list?
NIST's Cybersecurity Framework 2.0 places understanding assets, systems, suppliers and risks within an ongoing cybersecurity-risk-management model.
The principle is straightforward: you cannot maintain controls around an application you no longer understand accurately.
Security conditions can change without your own code changing.
A library already in production may receive a vulnerability disclosure. A framework can reach end of support. A runtime may stop receiving security corrections.
Maintenance should therefore check whether significant parts of the stack remain:
OWASP's Software Supply Chain Failures guidance specifically calls out vulnerable, unsupported and outdated software, including operating systems, databases, APIs, runtimes, frameworks and libraries. It also recommends tracking transitive dependencies and having an ongoing process for updates and configuration changes.
Do not translate this into "install every update immediately."
Instead, make sure every relevant security finding reaches an explicit decision:
Identify → assess exposure → prioritise → patch or mitigate → test → deploy → verify
If an urgent security correction cannot be released because nobody trusts the application's regression coverage, that is not just a patching problem. The application's maintainability is now limiting its security.
[Internal Link: “Application Security Maintenance: What Needs to Happen After Launch?”]
A list of active users does not tell you whether access is appropriate.
As applications grow, permissions become more complicated. Customers create their own administrators, employees change roles, support teams receive production access, contractors come and go, and integrations authenticate through machine identities.
Periodically examine:
OWASP's Broken Access Control guidance describes the consequences of users acting outside their intended permissions, including unauthorized disclosure, modification and destruction of information.
The maintenance question is therefore not:
Does this user still have an account?
It is:
Does this person or system still need every permission it currently has?
Also test authorization from the negative side. A billing administrator should be able to manage billing—but can that same role access employee records? Can one customer's administrator retrieve another customer's data by changing an identifier?
Successful access proves only half of an authorization model.
[Internal Link: “How to Maintain Authentication and Access Control in a Growing App”]
Authentication requirements should evolve with application risk.
An account that once controlled basic preferences might later provide access to financial information, enterprise data or administrative functions.
Review whether the current model still makes sense around:
Pay particular attention to recovery.
Strong MFA provides limited protection if an attacker can replace the MFA method through a significantly weaker recovery flow.
For sensitive actions, also consider whether a valid session alone is sufficient. Changing account ownership, replacing authentication factors or exporting sensitive data may justify recent reauthentication.
The objective is not maximum login friction.
It is keeping the strength of authentication proportional to what the account can now do.
A secure codebase can run with insecure configuration.
Cloud permissions change. Debugging is enabled temporarily. Firewall exceptions are created during troubleshooting. Storage permissions are widened so an integration can work.
The immediate change may be legitimate.
The problem comes when the temporary state becomes permanent.
OWASP's 2025 Top 10 places Security Misconfiguration at number two and identifies improperly configured applications and cloud services as a significant application-security risk.
Review for conditions such as:
Where practical, configuration should be version controlled or managed through repeatable deployment mechanisms.
The useful question is:
What differs from the intended production configuration, and why?
Applications accumulate machine credentials just as they accumulate user accounts.
These may include:
For each significant credential, know:
A five-year-old integration key may still be technically valid, but if nobody knows which systems depend on it, replacing it after suspected exposure becomes unnecessarily dangerous.
Good credential maintenance therefore includes changeability.
You should be able to replace important credentials without first conducting an archaeological investigation into your own system.
Security asks what must be protected.
Privacy adds another question:
What information are we collecting and why do we still have it?
Review data flows whenever the product begins collecting, deriving, sharing or storing new information.
For important personal or sensitive data, know:
GDPR Article 5 includes principles of purpose limitation, data minimisation, storage limitation and accountability. Personal data should be adequate and limited to what is necessary for its purpose and should generally not remain identifiable longer than necessary for that purpose.
Even when GDPR does not apply, these questions provide useful maintenance discipline.
A field introduced for a feature four years ago may no longer serve any purpose. A new analytics integration may now receive information that never appeared in the original data-flow diagram.
Privacy documentation should describe the application you operate today, not the application you launched.
A written retention policy is not the same thing as working retention.
If customer records should be removed after a defined period, verify the mechanism.
Check:
This can expose subtle drift.
Perhaps a deletion job covers the original database but not a storage service introduced last year.
The organisation may still believe it deletes the relevant data according to policy, while the technical implementation now leaves another copy behind.
Privacy maintenance requires occasionally following data all the way through its lifecycle rather than trusting that an old deletion process still reaches every location.
Not every feature needs a formal privacy assessment, but some changes should trigger the question.
Review privacy implications when introducing:
The best time to discover that data is unnecessary is before millions of records contain it.
Likewise, if a feature changes the reason information is used, that is easier to address during design than during the next compliance review.
Privacy should therefore appear in product-change discussions at the point where data decisions are still easy to change.
A third-party provider can affect security, privacy and compliance simultaneously.
It may introduce:
Maintain an inventory of significant vendors and integrations and periodically verify:
Do not assume that approving a provider once approves every future use.
An analytics platform originally receiving anonymous events might later begin receiving account identifiers because a new product feature needs customer-level reporting.
The vendor did not change.
The risk relationship did.
Logs are valuable for investigating suspicious activity, but indiscriminate logging can create its own sensitive data store.
Useful security events may include:
At the same time, logs should not casually capture passwords, tokens, secrets, payment details or unnecessary personal information.
The maintenance task has two sides:
Are we capturing enough information to investigate meaningful security events?
and:
Are we recording data that should not be there?
This balance may need revisiting when new features introduce different request fields or user information.
Logging an entire request object because it makes debugging convenient can quietly become a significant privacy and security issue.
A configured alert is not the same as an operational control.
Teams change. Slack channels disappear. Pager rotations are reorganized. Thresholds that worked under early traffic become meaningless as usage grows.
Periodically verify:
This is where Observable App Health reinforces Secure.
An application is better protected when suspicious behaviour becomes visible while somebody can still respond to it.
Do not measure the quality of security monitoring by the number of alerts produced. A small number of reliable, meaningful alerts is usually more useful than constant low-value noise.
Security and compliance maintenance become easier when repeatable controls run alongside normal engineering work.
Depending on the application, useful automated checks may include:
NIST's Secure Software Development Framework recommends integrating secure software practices into existing development lifecycles so organisations can reduce vulnerabilities in released software, mitigate remaining risks and address root causes.
Automation should target things that can be evaluated reliably.
It cannot decide whether collecting a new category of customer data is proportionate, whether a complex business permission is appropriate or whether a contractual obligation has changed.
Those still require human judgement.
Suppose a security review discovers that one API exposes another customer's records when an object identifier is changed.
Fixing that endpoint is necessary.
Maintenance should go one step further:
Why did the application allow this pattern to reach production?
Perhaps authorization is implemented separately in every controller.
The stronger remediation could therefore include:
NIST's SSDF specifically includes addressing root causes so vulnerabilities are less likely to recur.
This distinction matters throughout the checklist.
A good maintenance process does not repeatedly clean up the same class of problem.
It gradually changes the application or engineering process so that problem becomes harder to create again.
Compliance drift often begins when the application changes but the assessment scope does not.
Review whether new:
have changed the systems or controls relevant to an applicable requirement.
PCI DSS provides a useful concrete example. The PCI Security Standards Council identifies major software or infrastructure changes, changes to account-data flows, changes to assessment boundaries and changes involving relevant third-party providers as possible significant changes.
The specific PCI requirements only apply where PCI DSS is relevant.
The maintenance principle is much broader:
When a system changes materially, ask whether the compliance scope or controls changed with it.
[Internal Link: “Application Compliance Maintenance: Why Compliance Is Not a One-Time Project”]
Documentation can remain correct grammatically while becoming wrong operationally.
A policy may say:
Privileged access is reviewed regularly.
Verify that it actually happens.
A retention document may say:
Customer records are deleted after the required period.
Verify the deletion process.
Relevant evidence might include:
Evidence does not have to mean manual paperwork.
Strong engineering processes often generate it automatically through version control, deployment platforms, identity systems and ticketing workflows.
The aim is to be able to demonstrate that the control operated, not merely that somebody once wrote it down.
Real applications sometimes require temporary exceptions.
A patch cannot yet be installed. A legacy integration needs an older authentication mechanism. A migration temporarily creates another copy of data.
An exception can be reasonable.
An exception that nobody remembers is not.
For significant exceptions, capture:
The review date is essential.
Otherwise "temporary" has a habit of becoming part of the permanent architecture.
Security maintenance cannot assume every preventive control will succeed.
The application should remain capable of responding when something goes wrong.
NIST CSF 2.0 organizes cybersecurity outcomes around six functions—Govern, Identify, Protect, Detect, Respond and Recover—reflecting the need to manage incidents and recovery alongside preventive protection.
Periodically verify practical questions:
An incident plan referring to people, systems and tools that changed two years ago provides false confidence.
Exercise the parts that matter most.
Not everything should wait for a quarterly or annual checklist.
Certain events should trigger review because they can materially alter security, privacy or compliance.
Change
What deserves another look
Major framework/runtime upgrade
vulnerabilities, configuration, compatibility
New authentication method
authentication, recovery, sessions
New privileged role
authorization, access review
New API
data exposure, authentication, authorization
Sensitive data introduced
privacy, retention, compliance
New third-party provider
data sharing, credentials, compliance scope
Cloud/infrastructure migration
configuration, storage, control boundaries
New market or customer requirement
applicable compliance obligations
Security incident
affected controls and related weaknesses
This avoids two poor extremes.
You do not need a full security and compliance audit for every small code change.
You also should not wait until December to reconsider controls after fundamentally changing the way the application handles sensitive data in March.
Different risks change at different speeds.
A reasonable maintenance model therefore mixes continuous, release-driven and periodic checks:
Area
Typical approach
Vulnerability/dependency monitoring
Continuous or automated
Security-event monitoring
Continuous
Security regression checks
Relevant releases
Access/privilege review
Periodic + role/personnel changes
Secrets/certificates
Lifecycle-driven
Configuration review
Continuous/periodic + major changes
Data-flow review
Feature/integration changes + periodic validation
Retention/deletion validation
Periodic
Vendor review
Vendor changes + periodic review
Compliance evidence
Generated throughout operations
Compliance scope
Significant system/business changes
Incident readiness
Periodic + after incidents
Exceptions
Defined review/expiry date
Broader assessment
Risk-based periodic schedule
The exact frequency should reflect the application's exposure, data, business criticality and applicable obligations.
A public financial application and a low-risk internal utility should not be maintained as though their consequences of failure are identical.
For routine use, the full article can be reduced to three working views.
