How to Manage Auditability (and other non-functional, non-technical requirements)

Dave Gordon
Dave Gordon

This is a guest post by Dave Gordon.

One of the most common causes for IT projects to slip into “troubled” status is missed requirements.

In many cases, this is because the subject matter experts don’t think of all at the functional requirements at the beginning of the design stage. In other cases, technical requirements may be “discovered” during the execution stage, when the team starts to build the system that will deliver on the functional requirements.

But while there are clear sources (and advocates) for functional and technical requirements, there may be requirements which are neither functional nor technical, and the sources for these requirements may not be advocates for them during the course of the project.

In many cases, advocacy must fall to the project manager.

Consider the following attributes of a modern transaction processing system, whether located on a server in the corporate data center or delivered as Software-as-a-Service in the Cloud. Requirements associated with each of them may be a consideration for your next information technology project.

Auditability

Auditability is the degree to which transactions can be traced, from originator to approver to final disposition, through a system by an auditor.

Part of auditability comes from system documentation, and part comes from visibility of all integrity-related modifications to the system and to data records. Logs should make it possible for the auditor to determine who did what, when. Auditors may be either internal or external to the organization.

Once you’ve identified who will be the auditors for this system, work with them to ensure it will meet their needs. Naturally, they’ll want to validate and document that it does.

Security

System security refers to the control of access to a system’s resources, including both programs and stored data, to safeguard the integrity, authenticity, and confidentiality of the data and operating processes.

Security is implemented though a combination of internal controls and software, according to relevant standards and policies. Your organization may have a Chief Information Security Officer, whose staff is responsible for setting security standards.

Work with them to identify relevant security controls, how to implement them as procedures, and how to validate that they work correctly. The auditors will almost certainly be interested parties, so keep them in the loop.

Records Management

Most transactions are recorded for a specific purpose, and have a limited retention period. The record management policy for a particular record type should dictate when a record becomes obsolete, and must be purged.

In the event of litigation, a court order requiring preservation of records may override the policy.

Work with your Corporate Counsel or Chief Administrative Officer to identify the relevant policies and retention periods, establish procedures for requesting, approving, and documenting the destruction of obsolete records. In the case of compliance with a court order, ensure you have procedures to document the chain of custody, and control access.

Read next: Data protection considerations for your project (the GDPR angle and more)

Retirement

If your project is replacing a legacy system with a nice, shiny new system, part of your scope may be to create a project plan for retirement of the old system. This may involve a number of tasks, including:

  • purging obsolete records
  • archiving records not yet obsolete and not moved to the new system
  • notifying any number of interested parties
  • ordering the removal and disposition of the servers.

Work with the data custodians and the data center manager to identify the subject matter experts and conduct a stakeholder analysis.

As you’ve no doubt realized, Retirement overlaps with Auditability, Security, and Records Management. Ensure it’s a part of those conversations.

Final Thoughts

While these aren’t the sexy parts of an IT project, missing these requirements can still delay your project or put it over budget.

Make identifying the sources for these requirements part of your planning process, and ensure that your project budget and labor estimates reflect the level of effort required. If not, get out in front of it with a scope change. Your sponsor will (probably) thank you!

About the author: Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including both premises-based ERP solutions and SaaS solutions. He is the author of “The Data Conversion Cycle: A guide to migrating transactions and other records, for system implementation teams”.

This article first appeared in 2014 and has been lightly edited to update it. Dave has since retired (as far as I understand) but the issues of managing non-functional requirements are still relevant so I wanted to continue to share his work.