ID.AM-08 says systems, hardware, software, services, and data are managed throughout their life cycles. Security is not a gate at the start. It runs from the decision to buy or build, through configuration and use, to retirement and disposal. Most of the risk sits at the edges: systems deployed before they were hardened, and systems left running after anyone cared.
CSF is voluntary guidance and there is no CSF certification.
What good looks like
Each asset has a known stage: planned, in service, being retired or retired. Security checks happen at each stage change. Unofficial technology is found and either adopted properly or removed. Duplicate and unused systems are cleared out on a schedule because each one adds attack surface.
How to implement it
- Define stages for each asset class and the security step at each. Before deployment: secure configuration baseline applied and reviewed. In service: patching, monitoring and access review. Retirement: access removed, data migrated or destroyed, entry closed.
- Add the checks to existing workflows. A pull request template or launch checklist is better than a new committee.
- Find shadow IT. Compare SSO and OAuth grants, expense data and network egress with the official inventory, and talk to teams about what they use.
- Decide for each find: adopt (add to inventory and assess), replace, or shut down.
- Review redundancy twice a year. Ask which systems overlap, which have no active users and which run unsupported software.
- Track end of life dates for operating systems, runtimes and libraries and plan upgrades before support ends.
- For product teams, include security work in the product life cycle, with a defined end of support process and customer notice.
A worked example
A growth team signs up for a survey tool with a company email and connects it to the CRM. Three months later a review of OAuth grants shows the tool has read access to all customer contacts. Because the company runs a shadow IT review each quarter, the finding is routed to the supplier risk process. The tool is assessed, a narrower permission scope is set and the tool is added to the inventory with an owner. Had the review found nothing but an unused trial account, the account would simply have been closed. Either result is a win for the outcome.
Secure configuration before production
The last example in the outcome is to configure and secure systems before they go live. Make this checkable. Keep a baseline per platform, such as a hardened image or a set of infrastructure as code modules, and require that new deployments start from it. A pre launch checklist can confirm default credentials are removed, logging is on, patches are current, encryption is enabled and the entry exists in the inventory. Automated checks in the deployment pipeline are better than a checklist someone has to remember.
Retiring things properly
Retirement has its own risks. Backups still contain the data. DNS records still point at released addresses, which can be taken over by someone else. Service accounts keep working. A retirement checklist should cover: remove access and credentials, delete or archive data under your retention rules, remove DNS entries and certificates, cancel the contract, update the inventory, and notify dependents. Record completion with a date.
Reducing attack surface on purpose
Redundant systems add cost and risk without adding capability. A twice yearly review asks four questions about each system: does anyone still use it, does another system do the same job, is it still supported, and who would notice if it disappeared? Candidates for removal go on a list with an owner and a date. Shrinking the estate is one of the cheapest security improvements available.
Evidence to collect
- Lifecycle stages and the security step defined for each.
- Completed launch and retirement checklists.
- A shadow IT review with decisions recorded.
- A retirement log showing access removed and data handled.
- The end of life tracker.
Common gaps
- Retirement is never defined, so old systems run indefinitely.
- Configuration baselines exist but are not checked before production.
- Shadow IT discovery is a one off cleanup with no schedule.
- Orphaned cloud resources keep running because nobody owns them.
Quick check
What is the cheapest first step?
A launch checklist with three items: owner named, baseline applied, entry added to the inventory. Then the same for retirement.
Is shadow IT always a violation?
No. It is a signal that official tools do not meet a need. Treat it as discovery, then adopt, replace or remove.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
