Export usage and engagement history first, at the longest date range available, because it is the one asset that usually cannot be reconstructed later. Then verify row counts, file integrity, and date coverage before the system goes offline. Store the exports centrally with the export date in the filename so finance, security, and procurement can reuse them during rebuild work.
Why This Matters for Security Teams
When a SaaS management platform is being retired, the biggest mistake is treating the platform itself as the asset. The exportable usage and engagement history is the durable evidence trail that supports access reviews, license rationalisation, incident reconstruction, and vendor offboarding. Once the system is offline, those records are often gone or incomplete, which makes downstream reconciliation slow and brittle.
This is a governance problem as much as a technical one. Security, finance, and procurement typically need the same historical record, but each team uses it differently. Security teams need activity patterns and dormant account signals, finance needs spend and utilisation, and procurement needs renewal and vendor-performance context. Current guidance aligns with preserving evidence before shutdown, not after it, because retention settings in the source platform are rarely enough to satisfy all three functions. That is consistent with the broader lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the control prioritisation in the NIST Cybersecurity Framework 2.0.
In practice, many security teams discover missing SaaS history only after the renewal dispute, audit request, or breach review has already forced a rebuild.
How It Works in Practice
The safest approach is to treat export preservation as a controlled offboarding workflow, not an ad hoc data pull. Before the shutdown window, identify the reports that capture the widest possible date range and the clearest object scope, then export them in formats that can be reused outside the platform. If the system supports it, include logins, active usage, seat assignment, last activity, admin actions, and integration events. Where possible, preserve both raw exports and a normalised version for analysis.
Validation matters as much as collection. Teams should verify row counts, file hashes, and date coverage before decommissioning access. A short checklist usually works best:
- Confirm the export date range matches the business requirement.
- Compare row counts against in-platform totals or sampled reports.
- Record file names, export timestamps, and the owner who performed the export.
- Store files centrally with restricted access and a consistent naming convention.
- Retain a copy in a governed repository that security, finance, and procurement can all reach.
For identity and access teams, the retained history often becomes the only way to show who used the service, when access dropped, and whether a license or entitlement was ever actually active. That evidence is especially important when rebuilding controls across multiple SaaS tools, because the same user may appear in one platform but not another. The lifecycle model in NHI Lifecycle Management Guide and the NHI control themes in Top 10 NHI Issues reinforce the same principle: preserve evidence before the control plane disappears. These controls tend to break down when the platform has short notice shutdowns, because export privileges, API access, and admin consoles are removed before the final archive is complete.
Common Variations and Edge Cases
Tighter export governance often increases operational overhead, requiring organisations to balance evidentiary completeness against shutdown speed. That tradeoff is real when a SaaS vendor gives limited notice, when data is split across multiple workspaces, or when the platform only exposes partial history through its UI. In those cases, teams may need to combine UI exports, API pulls, and vendor-supplied archive files.
There is no universal standard for exactly how long SaaS usage history must be retained, so current guidance suggests aligning retention to audit, finance, and security needs rather than the vendor’s default deletion timeline. Where the data includes personal information, access must be limited and retention periods should be documented. If exports include cross-tenant data, shared admin activity, or delegated access, validate that the archive preserves enough context to support investigations without exposing unnecessary detail. The broader NHI evidence problem described in the State of Non-Human Identity Security is relevant here: visibility gaps are often discovered only after the system of record is already disappearing.
For teams comparing legacy reports against future replacements, the goal is not perfect historical replay. It is enough to preserve a trustworthy minimum record that can support decisions, approvals, and post-shutdown inquiries without relying on the retired platform.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Covers lifecycle offboarding and evidence preservation for non-human identity assets. |
| NIST CSF 2.0 | ID.AM-2 | Asset inventories need durable records when a SaaS platform is decommissioned. |
| NIST AI RMF | AI risk governance emphasizes traceability and documentation of important records. | |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero trust requires continuous verification of access to preserved archives. |
Archive SaaS usage evidence before shutdown and keep retained records tied to each identity lifecycle event.