ISO 27001:2022 – 8.10 Information deletion

There's a lot more to this than meets the eye...
David Morrison
July 20, 2023

This week we move onto ISO/IEC 27001:2020’s new 8.10 Information deletion control objective, one of the 11 new Annex A control objectives in the 2022 version. Information deletion is something I’m pretty passionate about, so it’s something I’m very happy to see included in ISO/IEC 27001. Having been working in infosec for so long, I’ve seen the results both first-hand and in the media too many times to count, of what happens when this simple control is not adhered to or performed half-heartedly.

In this article, like our other new ISO control articles, I’ll discuss what the intent of the control is and how you can comply, but for this control I’ll go a bit deeper to discuss how you can gain more from this control, and security practices in general, to reduce your exposure.

I love governance, risk and compliance, which should be pretty obvious seeing I started a GRC consulting company, but one of the many reasons our clients love us is because when we do compliance, it’s not a box-ticking exercise. I abhor compliance for compliance’s sake. When performed properly, compliance provides real value to your business, from securing your business through to providing differentiation in the marketplace. But one of the key benefits it can provide is making you a good human being. We live in a world where our clients and customers trust us with their information. The least we can do is protect that information as best we can, not just do the bare minimum so we can say we complied. And this is where information deletion comes in.

What is information deletion?

So first up, what do we actually mean when we say information deletion? ISO/IEC 27001:2022 Annex A 8.10 states:

“Information stored in information systems, devices or in any other storage media shall be deleted when no longer required.”

Pretty simple isn’t it? It’s exactly what it says. When you no longer need information, delete it! Don’t hold onto it because you might need it one day. Don’t hold onto it just because. If you don’t need it to provide your product or services, get rid of it. This simple control instantly reduces your risk and your exposure. If you’re hoarding decades of data, if you have a breach, that’s a LOT of data that gets exposed. Regularly deleting data when it is no longer needed can significantly reduce the consequences of a data breach. The extent of the impact on your clients or customers can also be minimised, depending on the type of data you retain.

Note that this control only addresses digital media and not other forms such as paper documents. Secure destruction of paper media is addressed in the 7.10 Storage media control objective.

What you collect dictates your exposure

While not part of this control, you can’t really discuss information deletion without discussing information collection. You know what reduces your need to delete data? Never collecting the data in the first place. Again, this reduces your exposure during a breach or a ransomware attack. If you don’t collect the data, it can’t be exposed or ransomed. We have all seen this time and time again. There will be a major breach in the media, they will tell us what data was exposed, and we all go “What??? Why were they even storing that information in the first place?” Organisations are renowned for collecting all the data they can, often just because they might need it one day, or for analytics, or for marketing purposes. But when you question their usage of that data today, they aren’t using it, don’t know how to use it, or the collection reason just doesn’t make sense.

A perfect example is signing up for rewards programs or some other online service. They ask you for your date of birth. Huh? This is personal information under every privacy regulation. You really don’t want to store it if you can help it.

Oh, you need it for demographics so you better understand your customer base? You could ask me my age. That’s all you need for demographics. Use my age + my signup date and you’ll know what my age is this time next year.

Oh, you need it so you can send me a free $20 gift card on my birthday? Why do you need the year I was born then? At least just ask me my day and month. Or better yet, do what the security-conscious businesses do and just ask your birthday month, and they send you a voucher on the 1st of the month for your “birthday month”. Easy!

Everyone needs to think before they request information and if you are part of a project that is about to collect this type of information, call it out and ask why. Do you actually need it? And if you do, is it worth the value or the risk you wear by storing it? And is it worth the cost of implementing the security controls around it, like ensuring its secure deletion when no longer needed?

Anyway, back on course for our new 8.10 information deletion control 😀

What is ISO 27001 Annex A 8.10’s expectation?

As I always do, let’s take a look at what ISO/IEC 27002 says about 8.10 as it provides us deeper insight and implementation guidance to comply with the requirement.

ISO/IEC 27002’s Purpose clause states:

“To prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion.”

The key words here are ‘unnecessary exposure’. This is exactly what I was just ranting about above. When you hold and store data, you increase your exposure. Get rid of it as soon as you can.

The first sentence of the Guidance clause states:

“Sensitive information should not be kept for longer than it is required to reduce the risk of undesirable disclosure.”

This is precisely why I talked about the collection of data. The ultimate compliance with “not be kept longer than it is required” is not collecting it at all. But of course. the majority of organisations cannot survive without the collection and use of some type of data. So we collect what we need, use it for as long as it’s needed, then delete it.

The control objective itself is very simple. It has two key components.

How to delete data

On the surface, this sounds pretty straightforward, but it can be complex.

First up, how will you delete data? Without delving into the technical details of file systems and how they manage and reference files, when you delete a file, it’s still there. Until it is overwritten with new data, it’s still possible to get that information back. You need a method that securely erases this data, such as overwriting deleted files.

What about duplicates of data? This is a massive issue within many organisations, especially when email is used to transfer files. Copies are made along the way, within multiple mailboxes. So while you may have had your data deletion processes in place and deleted a file from your file repository, such as OneDrive, it may still exist in countless other places.

How do you stay on top of your deletion requirements and ensure you delete the data when it’s no longer needed? For example, if you have ASIC requirements to store records for 7 years, how do you ensure files are deleted when the 7 years are up? This generally requires some sort of automation.

It should also be noted that this control is for the deletion of information no longer required for business purposes, and even though mentioned briefly within ISO/IEC 27002, deletion of data or destruction of media as part of equipment disposal or re-use is not a requirement of this control.  I’m not sure why it is mentioned within this control as it confuses the situation, especially as it mentions factory resetting smartphones and degaussing hard drives which are tasks you would usually only perform when disposing of these devices or when preparing them for re-use. ISO/IEC 27001:2022 has a separate control that addresses these requirements. 7.14 Secure disposal or re-use of equipment states:

“Items of equipment containing storage media shall be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.”

Recording the results of deletion

While not part of the Annex A Control objective statement, 27002 says you should consider:

“recording the results of deletion as evidence”

Note it says consider, not must or shall. Keeping records or artefacts for every piece of information deleted under this control would place undue burden on your business, and honestly, would provide little if any value. The issue is, a major part of ISO/IEC 27001 compliance is proving you are doing what you say you are, so you will be asked for evidence. Ideally, this task should be automated, which will then provide you with the audit logs you need.

One area where it does provide tangible value is where you have engaged a third party to store or manage your data and they have a requirement to delete that information. For example, if you cease services with a provider and you require them to securely delete all information they hold, you would want written proof that they have complied with this requirement.

To satisfy this requirement, if you do have cloud services or any other third parties that manage your data, you will need to ensure contracts with third parties have a clause that ensures secure deletion of data in line with your requirements, and that written proof will be provided on completion.

Unintentional exposure of information

One item that is briefly mentioned in ISO/IEC 27002 is the risk of exposure of information when equipment is sent back to vendors. This is something I have rarely seen addressed in most organisations as few identify this as a risk. It’s pretty good to see this mentioned as I thought I was the only one that lost sleep on this one 😂

As an example, faulty storage devices are often sent back to the vendor for assessment, repair or replacement, without any form of data deletion. It sort of makes sense though. If you have a hard drive that is no longer working, you can’t really run a secure wiping operation over the drive before sending it back. The issue is you have no idea where that drive is going or what happens to it. If it is repaired, who had access to the data and what system was it connected to for testing? If it’s not fixable, how is it disposed of? Data may still be recoverable from the drive. I know it sounds paranoid but depending on the data you may have, these are valid risks that should be assessed and appropriate requirements written into third-party contracts. In a past role, for servers with sensitive information, I had all support contracts state that failed drives did not have to be returned to the vendor. I then had them physically destroyed by a reputable data destruction company, and a destruction certificate was issued to me.

Data classification and lifecycle management

There’s an underlying principle to being able to comply with this requirement, and to gain any sort of value from complying, and that is understanding what data your business has, classifying this data, knowing how the business uses this data, where the data is stored, and how long the business needs the data. You also need to know your compliance obligations, not just in the information security domain, but across the business as these often contain information retention timelines that are legislated by the government or other regulatory bodies. So if you don’t have this information, this is where you need to start before trying to tackle this control. A data lifecycle policy is critical to successful data management and one of the first documents we develop with our clients.

How do I comply with ISO 27001:2022 Annex A 8.10?

So wrapping up, what do I need to do to comply with this requirement? I will break this into two parts as there are some prerequisites that will feed into the actual control and satisfying this control won’t be feasible without them. Or if you do skip these, you may comply, but the control won’t provide the same level of value.

Prerequisites

  • Document your compliance requirements, specifically data retention requirements, from across the entire business, not just information security. This will dictate when you can safely delete certain types of data.
  • Understand the types of information your organisation needs to do business. This will vary greatly between organisations but needs to include information created, downloaded, ingested, modified, stored, basically any way it is used. Understanding the information the business needs will allow you to define timelines for when this information is no longer needed. Some may be needed indefinitely. Some may have a short lifespan and become obsolete very quickly.
  • Understand where your information is stored, be that onsite systems, mobile devices, cloud services, or whatever. This includes backups. Different methods of deletion will be needed for different media and locations. And some will need to be performed by third parties if they manage or house your data.
  • Using all this information, develop a data lifecycle policy that will feed into your information deletion processes.

8.10 requirements

  • Define what methods you will use to delete information. This includes what secure file deletion software or tools you will use, and what methods you will use to automate this process. Where automation is used, use logging to provide artefacts that can be shown to auditors and also used to verify the process is working. If manual tasks are used (and please avoid this if possible), I recommend documenting when this takes place as your auditor will ask you. You will also need this information to perform any form of internal controls testing. Manual processes like these are prone to breakdown or being forgotten due to other BAU tasks, so knowing it is monitored also keeps you honest.
  • Ensure contracts with third parties contain relevant clauses that address your information deletion requirements, including methods of deletion.
  • Ensure contracts with third parties include issuing you with documented proof they have deleted your information when required.
  • Assess the risk of accidental exposure if devices or media are returned to vendors. Encryption at rest controls may reduce this risk in some areas, but again, this must be assessed. Ensure any contractual clauses are in place to reduce any identified risks.

If you need any help in this area, especially with the prerequisites above, reach out and we can have a chat. It can look daunting but we have gone through this successfully with many clients and have solid processes to simplify the task.

David Morrison

David Morrison

David is the Co-CEO of Morrisec. With a wealth of experience spanning more than two decades, David has established himself as a leading cybersecurity professional. His expertise and knowledge have proven invaluable in safeguarding organisations from cyber threats across a gamut of industries and roles.

0 Comments