Topic-specific policy 7/11: backup

This is an interesting policy example to have been selected for inclusion in ISO/IEC 27002:2022, spanning the divide between 'cybersecurity' and 'the business'.

Why do data need to be backed up? What's the purpose? How should it be done? Questions like these immediately spring to mind (mine anyway!) when I read the recommendation for a topic-specific policy on backup ... but as usual, there's more to it than that.

Play along with me on this worked example. If you already have a backup policy (or something with a vaguely similar title), I urge you to dig it out at this point and study it (again!) before returning to read the remainder of this blog. 

Think about it. Does it address those three questions? What else does it cover? What is its scope? Is it readable, understandable, motivational - not just for you but for its intended audience/s? Does it state who those audiences are? Any spelling mistakes, grammatical errors or layout problems? Is it lengthy, officious, boring? Conversely, is it short, cryptic and puzzling? Is it more of a detailed plan for what backups to do, when and how, than a clear and unequivocal statement of management's overall expectations re backups? Is it consistent both internally (no contradictions or omissions) and externally (e.g. does it accord with other policies and adequately reflect any applicable compliance requirements)? 

All good so far? 

If not, hopefully this blog series has given you food for thought! 

Either way, what is it missing? What relevant matters does your backup policy not cover, either failing to mention them at all or perhaps gloss over them too superficially to have any impact?

That's a harder question to answer, even if you were the one who wrote the existing policy. We all (me included!) tend to focus on our areas of interest and expertise. Policies are often formulated and written with particular scenarios, situations or incidents in mind, typically forming part of the response that drives continuous improvement. We don't always take the trouble to consult with colleagues, research the topic, explore the risks and controls, and think both broadly and deeply about the subject area - the topic of the policy. Frankly, we just don't think, failing to recognise and address our own biases and failings. 

Don't agree? OK, look again at the start of my second paragraph. I consciously slipped "data" in there, just as I deliberately mentioned "cyber" in the first one. Did you even notice the bias towards IT? 

Is your backup policy exclusively about backing up computer data, most likely digital data from corporate IT systems? Does it lay out the technologies, plus the frequencies and types of backup, in some detail?

Don't get me wrong, that's a very important topic, essential in fact for virtually all modern organisations and indeed individuals today. My concern is that it still only covers part of the problem space, a peak on the risk landscape you could say.

What about information in other forms and locations:

• Data somewhere out there in the cloud, perhaps dynamically shifting according to demand and supply of storage and processing facilities. 
• Data on workers' personal devices authorised under a BYOD scheme (or not!).
• Data on smartphones, laptops and all those IoT things proliferating like swarms of cockroaches in a horror movie. Is any important information stored in your car, for instance, or the smart bus ticket or passport in your pocket? How about the fancy coffee machine along the corridor? [Check your Y2K inventory for details. You have kept it running and up to date, right?] 
• Software, data, metadata and configuration items tucked away in RAM, in firmware, on computer chips and tapes and floppy disks and DVDs ...
• Backed up data: yes, backups are themselves valuable and yet vulnerable, so there may well be good reason to make additional backup copies and store them separately, at least for the most critical data that you really cannot afford to lose, ever. [Other controls and risk treatments are also available.]
• Data plus non-digital information stashed away in home offices, briefcases, purses and wallets.
• Information written on paper e.g. data entry forms, agreements and contracts formally completed and signed by customers and employees, scribbled notes from important meetings and interviews, annotated reports ... simply look around the offices or check your organisation's expenditure on paper and pens for clues about the amount of hardcopy information. 
• Intangible yet valuable information in workers' heads, as yet either unexpressed or shared verbally/informally and not recorded.
• Information belonging to third parties, placed in the organisation's care.
• Historical information - stuff that can become more valuable over time in contrast to most that loses its flavour as rapidly as stale chewing gum.
• Lower-value information that is untrustworthy, out of date, irrelevant or whatever - begging questions about what not to backup, given storage constraints and performance limitations of backup and recovery systems.
• Private information belonging to workers who just happen to be using corporate IT services and equipment.
• Information in obscure formats and obsolete media.
• Potentially valuable information that, for whatever reason, appears to be lost, perhaps tucked away in databases or disks that aren't properly structured, indexed, sorted and searchable.

And then there's the question of ensuring the availability of important information services, such as the Internet, as a whole. Down here on the Far Side in rural New Zealand, we have struggled with slow, expensive and unreliable Internet access ever since moving out of Wellington in 2006. All six technologies we have tried to date have been so unreliable that backup/fallback arrangements are essential, and yet unfortunately the backups are also unreliable. Even our last resort method (drive an hour into the city for WiFi or 4G ...) fails during COVID lockdowns. A Web-based business without Internet access is like hardware without software. The LEDs don't even flicker.

It should be obvious by now that challenging conventional boundaries or definitions is a legitimate, creative, even fun part of the policy development process ... but eventually the end product needs to reflect the intended purpose and scope sufficiently well to be accepted and mandated by management.  Scoping is a challenge in itself since the entire organisation uses and depends on information, hence information risk is (to some extent) relevant or integral to everything.  There is potential for turf wars if the information security policy suite dares to cross into areas such as HR, IT or procurement ... implying the need to appreciate and negotiate the boundaries and, if appropriate, collaborate with other functions to align the policies and practices for the best outcome - or, at the very least, to avoid conflicts and yawning gaps.

Narrowing the scope/coverage of a draft policy and focusing on its central aim/s is a useful way to reduce its size and complexity. There's a limit to what can be expressed in, say, 3 or 4 pages, given the need for various boilerplate clauses, and (most importantly) bearing in mind the poor person that ultimately must understand and comply with it. Here's what we came up with:

When we originally drafted the policy, archival was included as a special form of backup. Subsequently, we separated out the policies for backups and archives, partly to emphasise the differences in the information risks and hence controls required. You'll see also that in the end we stuck with data backups for this generic policy template, although we actively encourage customers to adapt the templates to their specifics. If you agree on the importance of having backups for critical information services, people etc., then by all means incorporate those aspects in your information security policy on backups, or develop separate policies, procedures, guidelines or whatever best suits your purposes - a policy on business continuity might be worthwhile, among others.

By the way, don't get too hung up on the nomenclature. I recommend reading Chris Hall's piece on LinkeDin for a discussion about the naming and structure of policies, procedures etc. Chris is a star, one of several greybeards generously donating their time to support the global community of 4,400 ISO27k fans on the ISO27k Forum.