Archives come in pairs

The topic for February: 'protecting information' is the working title, a deliberately vague term giving us plenty of latitude. 

Exactly what we will bring up, how we will raise and discuss things, the specific awareness messages we will be drawing out and so on is not determined at this point. It will become clear during January as we complete our prep-work and develop the awareness materials.

This morning, in connection with a discussion thread on the ISO27k Forum, I've been contemplating information risk management in a general sense by thinking through a situation, coming up with a specific example that draws out a much broader learning point.

Briefly setting the scene, the thread was started by someone asking whether it is really necessary under ISO/IEC 27001 to have a policy on risk-assessing valuable documents individually. We talked about grouping related assets together (such as 'Contents of cupboard 12') and controls (such as electronic backups) but the original poster circled back to the question of whether the ISO standard itself mandates a policy:

"I understood that I need to classify our assets according to their importancy and risk. But in general, would this cupboard-labeling method work according to ISO 27001 policies? For example, we have a lot of paperform documents in three cupboards and I would sort them all in some way, and make the cupboard lockable and label the cupboard according to the sorting and put the label into my inventory list. Would that violate any ISO 27001 policy?"

So this morning, I wrote this ... 

. . . o o o O O O o o o . . .

Here's an important information security control that, as far as I know, isn't explicitly mentioned in ISO27k (yet!).

• Do you have a formal archive - a dedicated long-term store for valuable information (physical information assets such as documents, computer data, records, forms ...) that needs to be retained for various reasons (legal compliance, business/commercial, history ...)? 

• Is all or much of the archived information literally or effectively irreplaceable? Would there be serious ramifications if it were lost or damaged? Isn't that precisely why you have the archive?

• OK then, so what happens if, despite all the controls, the archive is physically destroyed in a fire or a flood? What if some crazy over-stressed worker takes to it with a match or an axe? What if "the big one" hits, wiping out the archive facility? What if? Will insurance pay out, and will that be sufficient compensation (given that the archived content was “irreplaceable”)?

• So ... shouldn’t you have a backup copy, a duplicate or at least a facsimile of everything in the archive, stored separately, elsewhere? Shouldn't we be thinking and talking about 'a pair of archives' not 'an archive', in exactly the same way that we speak of 'a pair of trousers'? 

• Shouldn't there be strategies, policies and procedures concerning how the pair of archives are (is!) used, maintained and monitored?

• And yes, I am talking about (at least!) doubling the cost of archival, so it makes sense to be even more careful about determining what truly needs to be formally archived versus stuff that can simply be backed up and stored normally. Those strategies and policies are important business and information security tools.

• And, with this in mind, you can probably think of other archive-related risks, scenarios and controls … good on you! You’ve got my point! Good luck if you take it forward. 

To me, this is an obvious, straightforward control against a foreseeable risk, because I've identified and thought about the information risks, experienced at least some of the issues (e.g. floppy disks that can only be read on a specific floppy disk drive, due to head misalignment) and I've read about though luckily not experienced disasters that have destroyed archives (e.g. an Iron Mountain facility - a warehouse-sized commercial archive - went up in flames in London about a decade ago, and there have been others). I’ve considered all possible forms of risk treatment (accept, mitigate, share and avoid, remember) and thought about possible controls. It’s not hard really, if you start from the point of information risk identification and analysis.  

If, before you read this piece, you had never even considered it, and nobody in your organization had really thought it through (despite someone, somewhere, deciding that ‘an archive would be a jolly useful thing to have’), then there would have been no impetus to improve your archival controls.

This is just an example to illustrate the value of your ISMS and you entire approach in this area being risk-driven. The ISO27k standards, and methods, and books, and courses, and forums, and consultants and Google and so forth can help you enormously with possible risk treatments including controls, but calling on them for assistance won’t happen if you haven’t even identified the risks in the first place. 

Our journey starts right here: what are our information assets? What possible harm could befall those assets, or befall us in relation to those assets? What worries us most? And what are we missing?

. . . o o o O O O o o o . . .

The information-risk-driven approach will undoubtedly be a strong theme in February's materials, but exactly how we express and elaborate on it is unclear at this point. We may incorporate the pair-of-archives piece as an illustrative example, perhaps in the form of a case study, something that people can work their way through, thinking about a specific scenario and then drawing out the more general learning points. It might become an aside in the awareness presentations or briefings. We'll see.

But for now we need to think about those 'learning points': what are the awareness objectives? What are we hoping to achieve with the next module? Having engaged with and lapped up the content during February, how will security-aware workers think and behave any differently? Coming up with specific objectives will help us turn the vague 'information protection' title into something we can work with. That's our task for today.