Managing Auditability (and other non-functional, non-technical requirements)

Magnifying Glass ManOne 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 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.


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.


If your project is replacing a legacy system with a nice, shiny new system, part of your scope may be to 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; and 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!

This article was first published March 31, 2014 as a guest post on PM4Girls.

This entry was posted in Quality Management and tagged , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.