Your organisation invested in GPU infrastructure. You trained models, ran inference workloads, processed sensitive data. Now that hardware is at end of life and you need to decommission it.
Here is the question most IT and security teams have not answered yet: what happens to the data on it?
Not the data in your cloud environment. Not the data in your SAN. The data embedded in the hardware itself. In GPU memory. In NVMe arrays. In high-bandwidth memory modules. In the firmware caches of AI accelerator cards.
This is the AI hardware disposal problem. It is real, it is growing, and the majority of ITAD vendors are not equipped to handle it correctly.
Why Standard ITAD Processes Fail AI Hardware
The ITAD industry built its sanitisation processes around conventional IT: hard drives, SSDs and tape media. The NIST SP 800-88 Rev. 1 standard, published in 2014, reflected the storage technology of that era.
GPU infrastructure is different in three important ways.
First, GPU VRAM does not behave like a conventional SSD. Data written to VRAM during model training or inference is not stored in the same sequential blocks that standard overwrite tools target. Residual data can persist in memory cells that a conventional wipe tool never touches.
Second, NVMe arrays used in AI workloads write data across namespaces in patterns that differ from traditional SATA or SAS storage. A seven-pass overwrite that satisfies an HDD sanitisation audit will not guarantee data removal from a high-density NVMe array used to store training datasets.
Third, HBM3 high-bandwidth memory, which is the standard memory architecture in current-generation AI accelerators from NVIDIA, AMD and Intel, requires specialist sanitisation processes that most ITAD engineers have not been trained on.
NIST recognised this. In September 2025, NIST SP 800-88 Rev. 2 superseded the 2014 Rev. 1 document and included updated guidance covering modern storage architectures including those found in AI and high-performance compute infrastructure.
The problem is that most organisations are still specifying Rev. 1 processes in their ITAD contracts. And most vendors are still quoting Rev. 1 compliance. That gap is a live security risk.
The Business Risk Is Getting Worse, Not Better
The AI hardware refresh cycle is accelerating.
Organisations that invested in GPU infrastructure in 2022 and 2023 to support early large language model workloads are now starting to cycle that hardware out. The H100 clusters that were leading-edge eighteen months ago are being replaced by newer architectures. The volume of end-of-life AI hardware entering the market is increasing every quarter.
That hardware processed real data. Sensitive prompts. Customer queries. Internal documents fed into retrieval-augmented generation pipelines. In regulated sectors: medical records, financial data, legal documents, patient notes.
If that hardware is disposed of through a vendor who applies standard HDD sanitisation processes to GPU servers, the data is not gone. It is in a refurbished server somewhere, or in a recycling facility, or on secondary market hardware that has been resold without proper sanitisation.
This is not a theoretical risk. It is the same category of risk that led to the PSNI paying a £750,000 ICO fine in 2024 when hard drives left their custody without proper controls. The hardware type is different. The consequence is the same.
What NIST SP 800-88 Rev. 2 Actually Requires
NIST SP 800-88 Rev. 2, published September 2025, sets out three sanitisation categories that apply to AI hardware:
Clear. Overwrite processes that protect against simple non-invasive data recovery. For conventional storage this is often sufficient. For GPU VRAM and HBM3 memory it is not, because the memory architecture means simple overwrites do not reach all addressable cells.
Purge. Sanitisation that protects against laboratory-level attacks using hardware dissection and advanced recovery techniques. This is the minimum acceptable standard for AI hardware that has processed sensitive or personal data. It requires specialist tools and trained engineers, not a standard wipe utility.
Destroy. Physical destruction rendering the media unusable and unrecoverable. For hardware that has processed the highest sensitivity classifications, destruction is the only compliant option.
For most enterprise AI hardware, the correct approach is Purge-level sanitisation followed by a documented certificate of destruction that references the specific memory architecture, the sanitisation method used and the NIST Rev. 2 controls applied.
If your certificate of destruction from your ITAD vendor does not reference NIST SP 800-88 Rev. 2 specifically, and does not document the sanitisation method at the component level, it will not satisfy an ICO audit.
The ESG Dimension
AI hardware disposal also has an ESG reporting dimension that most sustainability teams have not picked up yet.
Under the UK Sustainability Reporting Standards, finalised in February 2026, organisations are expected to disclose Scope 3 Category 12 emissions, which cover the end-of-life treatment of products and assets. IT hardware disposal is explicitly within scope.
Your ITAD vendor needs to provide structured ESG reporting data that you can use in your Scope 3 Category 12 disclosure. Weight of assets processed. Recycling rates. Landfill diversion. CO2 equivalent avoided through refurbishment and resale.
A vendor who can only give you a certificate of destruction and not a structured ESG report is leaving a gap in your sustainability reporting as well as your security posture.
Three Questions to Ask Your ITAD Vendor This Week
Before your next hardware refresh, ask these three questions in writing and request documented answers:
Do you have a documented sanitisation process for GPU servers and AI accelerator hardware specifically aligned to NIST SP 800-88 Rev. 2, published September 2025?
Can you provide asset-level certificates of destruction that document the sanitisation method applied to each GPU, NVMe array and HBM3 memory module individually?
Do you provide structured ESG disposal reporting suitable for Scope 3 Category 12 disclosure under UK SRS?
If the answer to any of those is no, unclear or followed by a request to clarify what NIST Rev. 2 is, you have your answer about that vendor's capability.
How NanoSoft Handles AI Hardware Decommissioning
NanoSoft's AI hardware decommissioning process is built around four principles.
Correct sanitisation from the start. We apply Purge-level sanitisation to all GPU servers, AI accelerator cards and NVMe arrays, using methods aligned to NIST SP 800-88 Rev. 2. Our engineers are trained on the specific data retention characteristics of HBM3 memory and high-density NVMe namespaces.
Asset-level documentation. Every component receives its own certificate of destruction referencing the specific sanitisation method, the NIST Rev. 2 control applied and the date of destruction. No blanket certificates.
Full chain of custody. From collection at your site through transport to our facility, every asset is tracked using ISO/IEC 27037 aligned chain of custody documentation. You have a complete audit trail from desk to destruction.
ESG-grade reporting. We provide structured disposal reports covering weight processed, recycling rates, landfill diversion and CO2 equivalent data in a format suitable for Scope 3 Category 12 disclosure under UK SRS.
If you have a hardware refresh planned in 2026, get in touch before you commission your current vendor. The conversation takes twenty minutes and could prevent a significant compliance gap.
Contact NanoSoft at nanosoftltd.com or call 0800 677 1344.
AI hardware disposal is not the same as conventional IT disposal. GPU memory, NVMe arrays and HBM3 modules require specialist sanitisation processes aligned to NIST SP 800-88 Rev. 2, published September 2025. Most ITAD vendors are not equipped to deliver this. Most organisations have not updated their ITAD contracts to require it.
The risk is real, the volume of end-of-life AI hardware is increasing, and the ICO's track record on fining organisations for data disposal failures is established.
Ask the three questions. Review your vendor's capability. And make sure your certificate of destruction actually says what it needs to say.
NanoSoft Team
Writer at Nanosoft - covering ITAD, data security, and sustainable technology lifecycle management.
Found this useful? Share it.
