Asset Retirement Policy for PCs
A good asset retirement policy stops old laptops and desktops from becoming your next data breach or audit finding. It also makes offboarding and refresh cycles predictable, instead of a last minute scramble.
By the end of this article you will be able to define scope, set roles, pick wipe or destruction methods by risk tier, and document evidence that stands up in internal reviews. You will also have a step by step runbook you can turn into a one page SOP for your team and your ITAD vendor.
Note for South Africa:
- Plan retention and deletion around POPIA, including the need to destroy or delete personal information so it cannot be reconstructed in an intelligible form.
- Do not let statutory record keeping needs drive you to keep data on endpoints, migrate it to approved systems before wiping.
- Use responsible end of life routes and vet recyclers, South Africa’s EPR framework and e-waste realities make vendor due diligence important.
At a glance:
- Define what counts as retirement, including drives, removable media, and accessories that may hold data.
- Classify devices by information risk tier, then choose Clear, Purge, or Destroy outcomes to match.
- Run a repeatable workflow: ticket, identify, approve backup, deprovision, sanitise, verify, log chain of custody, dispose.
- Make evidence mandatory, wipe logs, verification steps, and certificates of destruction where needed.
Key takeaways:
- Policy first, tools second, the tool must serve your sanitisation outcome and evidence needs.
- Chain of custody is as important as the wipe itself.
- Retire data, not just devices, move records to compliant storage before the endpoint is sanitised.
What an asset retirement policy is, and where it fits in the IT asset lifecycle
An IT asset retirement policy is the documented rule set for removing a device from service, sanitising any data it may contain, and moving it to a final disposition route. It sits at the end of the asset lifecycle, but it should be designed to work with procurement, onboarding, and device management from day one.
When the policy is clear, you avoid two common failures, devices that leave the building without proof of sanitisation, and devices that are wiped before the business has retained what it must keep. In practice, retirement touches service desk tickets, MDM actions, finance write off, and vendor logistics.
Use the policy to standardise decisions. For example, when a laptop comes back from an offboarded employee, the policy should say who approves data migration, which sanitisation outcome applies, and what evidence gets stored.
If you want a service provider to handle collection and disposal, your policy becomes the minimum standard they must follow, not a nice to have.
Scope and definitions (laptops, desktops, SSDs, HDDs, removable media, accessories)
Scope answers the question, which items must follow this process. Keep it explicit so nothing falls through the cracks during busy refresh cycles.
- Devices: laptops, desktops, workstations, thin clients, and any company owned endpoint used for work.
- Storage media: internal SSDs and HDDs, external drives, USB sticks, SD cards, and any removable media issued by the company.
- Data bearing components: devices with soldered storage, embedded modules, and hardware that may store logs or credentials.
- Accessories: docks, printers, and peripherals that can retain job data or configuration, treat as in scope if they store data.
Define your key terms in plain language. Good starting definitions are: retirement, redeploy, sanitisation, destruction, donation, resale, recycling, and chain of custody.
Also define what is out of scope, for example employee owned devices, unless they are enrolled in corporate MDM and you explicitly cover them.
Roles and responsibilities (IT, InfoSec, Legal, Finance, HR, Facilities, third-party ITAD)
Most endpoint incidents at retirement time are not technical, they are ownership gaps. Your policy should map each step to a role and a named approval level.
- IT operations: runs the workflow, executes sanitisation, and maintains tooling and logs.
- Information security: sets risk tiers, approves sanitisation methods and verification, and audits evidence.
- Legal and compliance: advises on retention constraints and contract wording, especially for vendors.
- Finance: asset register updates, write off triggers, and resale controls.
- HR: offboarding coordination and employee communications about device return timing.
- Facilities: secure storage areas, cages, and access control for retired assets.
- Third party ITAD: collection, transport, processing, and certificates, under contract and SLAs.
Write down who can override the default route. For example, a device associated with an investigation may require a legal hold, and must not be wiped until approved.
Make it clear that employees should never self wipe and hand back a device. You want consistent evidence and consistent handling of encryption keys and accounts.
Data handling rules by risk tier (public, internal, confidential, personal information)
Risk tiering lets you scale controls without forcing maximum security on every low risk device. Keep tiers simple, but tie them to real examples in your environment.
- Public: information intended for external release.
- Internal: operational information not meant for public sharing.
- Confidential: sensitive business information, customer data, credentials, or security related data.
- Personal information: data that is regulated under POPIA, including employee and customer information.
Assign a default tier per device type and user group, then allow escalation when needed. A CFO laptop and a reception kiosk should not follow the same default sanitisation outcome.
Build in a retention check before any wipe. For personal information, POPIA’s retention and deletion principles should be reflected in your process, including the requirement that deletion or destruction prevents reconstruction in an intelligible form, see POPIA Section 14 guidance at POPIA Section 14 retention and deletion.
Sanitisation decision logic (Clear, Purge, Destroy) aligned to NIST SP 800-88
Use an outcomes based approach rather than arguing about tools. NIST SP 800-88 Rev. 2 describes sanitisation outcomes and a program approach, which helps you justify why a method is sufficient for a given risk tier, see NIST SP 800-88 Rev. 2 clear, purge, destroy.
Keep your policy aligned to three outcomes, even if your tooling differs by device.
| Outcome | When it fits | Typical endpoint approach | Evidence to keep |
|---|---|---|---|
| Clear | Lower risk internal use | Approved overwrite or reset plus verification | Tool log and spot check result |
| Purge | Higher risk, resale, or cross boundary | Cryptographic erase or firmware secure erase where supported | Tool report, method recorded, verifier sign off |
| Destroy | Failed wipe or highest sensitivity | Physical destruction via approved process | Certificate of destruction and chain of custody |
Translate this into your real world decision tree. For SSDs, a simple overwrite is not always the best fit, so your policy should prefer vendor supported secure erase methods or cryptographic erase where encryption is properly implemented and keys are handled correctly.
Also include a failure rule. If a drive fails, BitLocker recovery is unavailable, or verification cannot be completed, the policy should default to physical destruction for the affected media.
Retirement workflow (from user offboarding to final disposition)
This is the part most teams need. The goal is a repeatable runbook that any IT technician can follow, with approvals and evidence built in.
Step by step retirement runbook (use as your SOP):
- Create an intake ticket: link the retirement to an offboarding request, refresh project, or incident ticket, and capture required dates.
- Identify the asset: record asset tag, serial number, user, department, and current location, then match to the asset register.
- Check for legal hold: confirm there is no investigation, dispute, or HR matter requiring the device to be preserved.
- Confirm data migration: get owner approval that business data is synced or backed up to approved storage, not left on the endpoint.
- Recover licences and access: deallocate software licences where applicable, and remove device from privileged groups.
- Deprovision accounts and tokens: sign out of corporate accounts, remove MFA tokens tied to the device, and rotate local admin credentials if used.
- Handle encryption keys: record encryption state, and ensure key escrow or recovery processes are followed, especially before any reset action.
- Select sanitisation outcome: choose Clear, Purge, or Destroy based on risk tier, media type, and final disposition route.
- Execute sanitisation: run the approved method, for example secure erase, cryptographic erase, or controlled destruction.
- Verify: perform verification appropriate to the method, capture logs, and do a secondary check when required by tier.
- Log chain of custody: record who handled the device at each handoff, where it was stored, and how it was sealed for transport.
- Store securely pending disposition: use a locked cage or room with access control, and keep devices segregated by status.
- Route to final disposition: redeploy, sell, donate, recycle, or destroy, and ensure the route matches the sanitisation outcome.
- Capture certificates and close out: store wipe reports and certificates, update the asset register, then close the ticket with approvals attached.
For organisations using Microsoft management, document where reset actions fit and where they do not. Autopilot Reset is designed to prepare a device for the next user and has prerequisites like Windows Recovery Environment, see Windows Autopilot Reset requirements. Your policy should still require evidence and verification that meets your chosen sanitisation outcome.
Chain of custody, evidence, and certificates (what to log and who signs off)
Evidence is the difference between a good process and a defensible process. Build a minimum evidence pack per device, then add extra controls for higher tiers.
- Chain of custody log: every handoff, time, location, and person responsible.
- Sanitisation record: method, tool, version where possible, and pass or fail result.
- Verification record: who verified, what was checked, and any exceptions.
- Disposition record: redeployed to whom, sold under which process, donated to which organisation, recycled by which recycler, or destroyed.
- Certificates: certificate of destruction or recycling confirmation where applicable.
Make sign off explicit. For example, IT executes, InfoSec verifies for confidential tiers, and Finance confirms write off or resale authorisation.
Appendix, sample asset retirement log fields:
- Ticket ID, asset tag, serial number, device model, business unit
- User and manager, offboarding or refresh reference, return date
- Data owner approval date, backup location reference
- Encryption state, key escrow status, special notes
- Risk tier, sanitisation outcome, method used, tool output reference
- Verification result, verifier name, date
- Chain of custody entries, seal numbers if used
- Final disposition, vendor details, certificate IDs
- Asset register update date, close out approver
Reuse, resale, donation, recycling, and disposal, including environmental compliance considerations
Your policy should state the allowed disposition routes and the minimum controls for each. The route determines how strict your sanitisation and cosmetic inspection needs to be.
- Redeploy internally: usually allowed after Clear or Purge depending on tier, plus hardware health checks.
- Resale: usually requires Purge level outcome, plus removal of asset tags and organisation identifiers.
- Donation: treat like resale, because you lose control of the device and the recipient may not manage it securely.
- Recycling: ensure data bearing components are sanitised or destroyed before leaving controlled custody, depending on tier.
- Destruction: required for failed wipes and for some high sensitivity device classes.
For South Africa, include a short environmental compliance section. If you want context on the EPR framework, you can reference an overview such as overview of South Africa EPR regulations and supporting notice context under the Waste Act such as Waste Act EPR notice and reporting.
In practice, this means you should vet your downstream partners. Ask how they handle hazardous components, where shredding happens, and whether they subcontract any part of the process.
Retention and deletion: aligning POPIA and business record-keeping needs before wiping
Many IT teams confuse device retention with record retention. You rarely need to keep an old laptop to keep the records that matter, you need to migrate data to approved repositories and then dispose of the endpoint safely.
At minimum, your policy should require a retention check before sanitisation when the device belonged to finance, HR, legal, or anyone handling customer personal information. POPIA Section 14 is a practical reference point for when personal information must be destroyed, deleted, or de-identified when no longer authorised, and it emphasises preventing reconstruction in an intelligible form, see POPIA Section 14 retention and deletion.
For tax and statutory business records, link your process to an agreed retention schedule owned by compliance. SARS provides general record keeping guidance and common retention rules, see SARS record-keeping requirements.
Practical policy wording that works is, endpoints are not archival storage. If records must be kept, move them to approved systems with access control, backups, and audit trails, then wipe or destroy the endpoint per tier.
Tooling and automation options (MDM, Autopilot, remote wipe, inventory systems), plus common failure modes
Tooling should reduce technician time while increasing consistency. The policy should name categories of tooling rather than a single product, unless you are standardised and willing to maintain the policy when platforms change.
- MDM and endpoint management: remote lock, reset, and wipe actions, plus compliance reporting.
- Encryption management: key escrow and reporting to support cryptographic erase decisions.
- Asset inventory: asset tag tracking, location history, and integration with the service desk.
- Wipe tooling: approved secure erase tools that can produce logs and reports.
- Ticketing and workflow: mandatory fields, approvals, and evidence attachment.
If you are using Windows Autopilot Reset for redeployment, document prerequisites and failure handling based on Microsoft documentation, see Microsoft guidance for device reset and redeployment. Then decide whether a reset is sufficient for your risk tier or whether you require a Purge outcome.
Common failure modes you should plan for:
- Drive failure or read errors, making software sanitisation impossible.
- Encryption state unknown or keys unavailable, making cryptographic erase unverifiable.
- Recovery environment missing or misconfigured, causing reset actions to fail.
- Device cannot boot, so remote actions do not execute and local tools cannot run.
- Human errors, wrong device wiped, missing asset tag, or evidence not uploaded.
Your policy should include an exception path. When sanitisation cannot be completed and verified, escalate and move the media to controlled destruction with documented approvals.
If you need help designing a workable workflow and evidence pack, your quickest path is to align policy, storage, and vendor operations together, and then document it as a single SOP, you can also reach out via our contact page.
Common mistakes
- Relying on ad hoc technician judgement, instead of a written decision logic by risk tier.
- Letting devices sit in cupboards without chain of custody or secure storage.
- Wiping first, then discovering a retention or legal hold requirement.
- Sending devices to a recycler or buyer without evidence of sanitisation.
- Using consumer reset features as a substitute for a documented sanitisation program.
If you’re new
- Start with a simple 3 tier risk model and a single runbook, then add complexity later.
- Pick one evidence pack that every device must have, even low risk devices.
- Set up a secure storage area with restricted access before your first collection run.
- Build a basic vendor checklist and insist on written chain of custody.
- Publish the SOP where the service desk and technicians actually use it.
If you have done this before
- Audit your last 20 retirements, check whether you can prove sanitisation and custody for each.
- Separate redeploy and resale pathways, resale usually needs stricter controls.
- Automate required fields in tickets, missing data is your biggest blocker in audits.
- Test failure paths, especially broken drives and encrypted devices with missing keys.
- Review vendor contracts for confidentiality, subcontracting, breach reporting, and evidence SLAs.
Frequently asked questions
Do we need to physically destroy every drive?
No. A policy aligned to outcomes like Clear, Purge, or Destroy lets you use verified sanitisation methods where appropriate, and reserve physical destruction for the highest risk or when wiping cannot be verified, guided by NIST media sanitization guidance.
Is a Windows reset the same as sanitisation?
Not automatically. Reset actions can be useful for redeployment, but your policy must decide whether the result meets your required outcome and evidence standard, and you should document prerequisites and limits, see Windows Autopilot Reset requirements.
How long should we keep wipe logs and certificates?
Set a retention period that matches your internal audit needs, contractual requirements, and your organisation’s records schedule, then keep the evidence in a controlled repository rather than on endpoints. For tax related record keeping context, see South African tax record retention periods.
What about devices that may have data outside the main drive?
Write into your policy that removable media, external drives, and any data bearing peripherals issued by the business are in scope, and must be sanitised or destroyed using the same risk based logic. Where you cannot practically verify sanitisation, route that component to controlled destruction.
How do we vet an ITAD vendor in South Africa?
Start with chain of custody, evidence quality, and contract clauses for confidentiality and subcontracting, then validate their downstream recycling and disposal approach. For environmental context, reference the EPR framework for electronics end-of-life.
Where this policy fits on Sell Your PC
If you are building a complete process, it often helps to pair your internal policy with an external service that can handle collection and downstream processing while still meeting your evidence requirements. You can review our corporate IT asset disposal service and the broader professional services options, or browse more operational content in Sell Your PC Expert Insights.
For organisations that want a clear buy back or redeployment path, you can also see what we accept via sell your items and product categories in our shop.
Summary
- Define scope clearly, including media and data bearing accessories.
- Use risk tiers and outcome based sanitisation logic, then verify and document.
- Run a single workflow from ticket to disposition, with approvals and evidence.
- Keep endpoints out of your retention strategy, migrate records first.
- Vet vendors and recyclers, and keep chain of custody end to end.
This is educational content, not financial advice.
