Assessing information risks in business systems and working out what to do about them February 20, 2013

Yesterday we ran another of our Managing recordkeeping risk in business systems workshops. It has been a while since I have posted an update about this workshop and we had a really great group in yesterday with lots of interesting discussions, so here is a summary of some of the key points we talked about.

What are information risks?

The workshop basically says that in the digital business environment, information risks are very real for all organisations but they are generally not proactively identified or addressed.

Information risks are different to business continuity risks. Business continuity planning is concerned with managing information so that it can be reconstructed tomorrow should something terrible happen to it today. Information risks however occur every day, but might particularly be likely to occur at:

  • system design, implemention and configuration
  • system integration
  • system migration
  • record format selection
  • transitions to cloud environments.

If information use and management requirements are not considered and specifically managed at these points, some of the particular risks that can eventuate are:

  • information will not be maintained
  • information that is maintained will be incomplete
  • information will be meaningless and unable to be understood
  • information cannot be trusted
  • information will be corrupted
  • information will be inaccessible
  • information will not survive for as long as your business needs to access it.

The workshop is based on a series of case studies that look at what you need to do to assess and mitigate the risks that could affect your information at system implementation, integration, migration etc.

These are some of the key points that emerged during our discussions yesterday.

Keep your focus on high value and high risk

We talked quite a lot about not having to make comprehensive records of all your business systems. Instead, by focussing on the high risk areas of your business and the business areas that have business and legal requirements to keep information for long periods of time, you can prioritise your efforts and make sure that these core environments are supported by good and robust information.

Bringing an awareness of your operational business system environment too can help you to determine where information risks are likely to occur.  For example, think of key instances where you know your records are going to have to outlive the business system they are currently part of. To mitigate the risks that could occur if this information does not survive, you may need to make sure that the business application has export capacity, that you have good metadata for your records, or that their system migration is adequately planned, and that necessary aspects of the records and their metadata can be maintained through system change etc.

Social media

As usual social media information management was a topic of of great interest. As an emerging technology in many organisations that is very likely to grow rapidly, we discussed that now is the time to get in and develop recordkeeping strategies that will enable the business information you need to be harvested from these systems.

We discussed the fact that there may be compliance drivers to have records of high risk social media accounts, but also flagged that a lot of business intelligence and insight can come from using social media generated information. The community is contributing a lot of feedback and information to government through social media and good information management can be a way to ensure this feedback is built into relevant business processes.

We discussed how State Records’ draft social media guidelines contain some advice on strategies for capturing social media records and social media information management strategies.


Throughout the day, it was interesting how metadata came up as an issue nearly all our discussions. In a variety of the case studies we assessed, the problems identified all hinged on metadata.

Metadata, we decided, needs to be:

  • well designed
  • well implemented
  • made simple for users
  • documented as a record itself
  • re-documented when it is changed or updated
  • applied well by users.

If it is not, so many risks, costs and problems can eventuate.

In particular we talked about the critical 15 second window when a user is applying metadata to a record. If that metadata is poor, the record’s usability from that point on is fundamentally flawed. And if that record needs to be kept for 5, 10, 50+ years then that poorly used 15 second window has very, very long term ramifications. So talking business and ICT colleagues about the long term value of good, accountable, meaningful and useable metadata was a popular topic in our discussions.


We also talked a lot about wikis, and how these provide fantastic functionality for project teams to work collaboratively and share documentation, but how they also pose a variety of challenges information governance, continuity and reuse.

For instance, the functionality offered by wikis means that they are used by project teams who are doing quite strategic work. This means that the information being created on wikis can have high and long term value for an organisation. But teams also have a lot of autonomy on wikis. They can set up security so only certain groups have access to documentation. Teams can remove documentation permanently when they want. Given the team or project based structure of many wikis, it can be hard for any one person or group to ever have a comprehensive understanding of all the documentation and information that actually exists in a corporate wiki environment.

It is really important then for project teams to sit down and discuss information governance, discuss what information they are generating and what the organisation’s medium to long term requirements for this data are. With this understanding in place, recordkeeping strategies can be developed to make sure necessary information can be captured and its continuity managed. Without this understanding, information management will be ad hoc, fragmented or likely to not occur at all in many wiki environments. We also discussed how wikis are generally cloud-based and how some wiki technologies have no export functionality. Information continuity management in these environments can then be particularly problematic.

Action items

At the conclusion of the workshop participants developed a great set of action items, listing the things that they were going to go back and implement in their own organisations. These action items included:

  • investigate RSS feeds as a simple but effective mechanism for capturing social media records
  • develop a presentation on wiki-based recordkeeping requirements for business colleagues
  • develop a recordkeeping strategy for high risk business users of SharePoint
  • develop an inventory of corporate business systems and assess their specific information risks 
  • ensure that digitisation strategies are continuing to meet business needs and requirements
  • liaise with business staff to ensure that the metadata they create is accurate, useful and meaningful

Another participant is going off to create an information risk register. Each organisation tends to have many risk registers and has existing reporting, assessment and project responsibilities for managing and mitigating these business risks. Creating an information risk register to elevate information risks to the same level as other organisational risks was therefore a great idea.

An information risk register could identify the high risk, long term value business information in an organisation, the ICT related vulnerabilities that could impact upon it and strategies for mitigating these vulnerabilities.

Specific risks that the register could identify could include the impacts on service delivery and accountability if:

  • certain system information is altered or removed in system migration
  • certain long term value business data is not supported in new system environments
  • a core business system cannot export data of its transactions
  • sections of a wiki or SharePoint environment used to manage project information are deleted by project staff who don’t recognise the core business information that needs to be kept
  • information requirements are not built into contracts with providers building or managing assets on the government’s behalf
  • information requirements are not factored into migration planning and implementation
  • apps with no information export functionality are implemented in corporate mobile devices
  • connections between data and metadata are lost, resulting in completely unintelligible and unusable information

Don’t get overwhelmed and be proactive

Finally, we also talked about the need to be so proactive in relation to digital information management. Identifying and mitigating risks up front is so much more effective than attempting to remediate risks down the track.

And with the litany of problems that can occur, we also discussed the need to keep focussed on supporting business needs, supporting business risks and supporting long term information requirements. Prioritise your system assessments and mitigation efforts on high risk business systems, and on the information that your organisation is going to have to use and rely on for long periods of time. Also, if you know particular technologies are vulnerable and cannot be relied upon to support your business information, make sure you also assess these.

So thank you very much to the excellent and enthusiastic group of participants we had yesterday. I had a great time and learned a lot and hope you did too.

photo by: Unsworn
Bora Wiemann February 21st, 2013

What were the thoughts of the group in regards to the association of metadata and using RSS feeds to capture social media records?

If the group identified good metadata as such a critical component, than RSS feeds aren’t the easiest option for good metadata. The feed might include a bunch of metadata within the feed (like metadata hidden in a document), but extracting it to use for the classification of each object requires quite some work. And in most cases one still doesn’t even have the minimum record keeping metadata set.

So how to tackle this problem?

Kate Cumming February 22nd, 2013

Hi Bora – thanks again for another useful comment. Yes, you are right. RSS is a means of capturing content. Attributing metadata to this content has to pretty much be a manual process. You have to know what metadata to tag it with and then make sure this is actually done. Cheers, Kate

Kate Cumming March 14th, 2013

Hello, thank you for your feedback. Cheers, Kate

Leave a Reply

You must be logged in to post a comment.