How should security issues be dealt with in contracting for IT services? Where do we even start? "Let's talk about it later" someone pipes up and it's forgotten until it is too late.

2016 is looking to be another big year in the world of data security as excitement builds for the Australian Government's annual Australian Cyber Security Centre Conference to be held in Canberra in early April. Companies are looking to implement robust security measures in advance, rather than learning from security incidents or breaches, which have proved to have devastatingly expensive and negative consequences in the past. (Click here to view security incident examples as described in the Ponemon report.)

Data security should be discussed early in the transaction process. Formulating what data will be involved as part of IT services is key to determining appropriate security requirements. It may be clear at the outset that the data is discrete and fairly specific, for example, an employee's payroll data. Alternatively, parties may determine that categories of data would work better if specificity is not possible, for example, financial data of the customer.

It is tempting to be as broad as possible, often using the supposedly all-encompassing but also highly ambiguous phrase, 'all data'. This is usually an indication that the parties did not leave enough time to clarify data issues or that the services have not been fully scoped.

Obtaining a better understanding of what data will be involved also helps to clear the path to discussing who is responsible for what aspects of the data's security. Don't leave this discussion in the "too hard" basket. The customer sometimes believes the supplier as the IT expert should be handling things and the supplier claims the customer should be responsible for the protection of their own data - a standoff follows…

Each party should assess its own operational data security regimes, which are separate from any additional security services that may be required. Think practically about likely security risks and allocate responsibility for each aspect of data protection for the duration of the services. A responsibility matrix is often helpful to map out what tasks are required and who will be responsible.

In some situations, the customer may also need consulting or penetration testing to identify any weak spots in its own regime. Depending on the type of services, additional measures may be required from the supplier.

The idea is to be realistic in analysing hypotheticals of areas where there may be a lapse in security. It's easy to get bogged down by endless horrific scenarios. The zombie apocalypse is one that pops up more often than it really should. Think within the context. It may not be realistic to request broad security obligations from the supplier if the supplier has no access or visibility to encrypted data held by the customer. Likewise, it may not be workable for the supplier to avoid responsibility for loss or damage of data if it is involved in back up services.

Quality security services don't come cheap either. Forbes has reported global spending in the cybersecurity market estimated to grow to $170 billion by 2020. Avoid throwing the budget or cost model out of whack by talking about data security requirements early.

And if the zombie apocalypse does happen? We are all doomed but our data will be secured.