Auditing Requirements are Tricky. Isn’t it?



Many a project I worked upon, did not have a clear stated set of requirements related to auditing. Interestingly, with some projects, the auditing related requirements were created only after a couple of releases and got prioritized as less important in that specific release. One of the common observation I made across these projects is lack of understanding of auditing requirements and its significance, to key stakeholders including product owners, business analysts, developers and testers. Most of them could not figure out a strong reasoning in relation with why do we need to take care of audit trail of one or more transactions, until they got addressed/questioned by a security expert/officer/architect during review of application requirements/code review etc.

Before we go on why and when do we need to implement auditing requirements, lets understand what looks like auditing requirements?

What looks like auditing requirements?

Auditing requirements primarily looks like recording the information related with transactions such as who performed the transaction, when was it done, what is its detail etc. The transactions can be of many types such as financial (order/cancel/pay etc), workflow approvals/rejections etc. As per wikipedia, following is how auditing is defined as:

Auditing is defined as a systematic and independent examination of data, statements, records, operations and performances (financial or otherwise) of an enterprise for a stated purpose. In any auditing the auditor perceives and recognizes the propositions before him for examination, collects evidence, evaluates the same and on this basis formulates his judgment which is communicated through his audit report

Why at all is auditing requirements needed to be implemented?

Repudiation - Act of challenging the authenticity of transaction

Repudiation – Act of challenging the authenticity of transaction

Auditing requirements need to be implemented primarily to handle/manage repudiation attacks. Repudiation attacksĀ  happens as a result of data manipulation without any logs followed by the act of refusing and no longer accepting a transaction that one performed. The authenticity of the data/transactions when challenged is called the state of repudiation. And, for organization to proveĀ  otherwise, they need to show the evidence that the transaction was performed. This is where auditing related data needs to be recorded for key transactions.

When & how does one figure out the auditing requirements?

The auditing requirements mostly remain implicit. Until the business analyst (BA) has the knowledge on threats related with Repudiation (refer STRIDE model), the auditing requirements go unnoticed. During business analysis process, BA needs to check with business users on what are sensitive data and key transactions which could have significant impacts such as financial loss if one refuses to accept that he/she was responsible for change or doing the transaction. Once these data and transactions are identified, the BA would like to put the auditing requirements around these such as recording information about any change of this sensitive data or, information (who, when, what, where, why etc). about the transactions.

Identifying auditing requirements during requirements gathering phase

Identifying auditing requirements during requirements gathering phase


Once business analysts (BA) documented the auditing requirement, developers need to put a design around audit including appropriate data model, and modules to manage the auditing data.


Ajitesh Kumar
Follow me

Ajitesh Kumar

I have been recently working in the area of Data analytics including Data Science and Machine Learning / Deep Learning. I am also passionate about different technologies including programming languages such as Java/JEE, Javascript, Python, R, Julia, etc, and technologies such as Blockchain, mobile computing, cloud-native technologies, application security, cloud computing platforms, big data, etc. For latest updates and blogs, follow us on Twitter. I would love to connect with you on Linkedin. Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking. Check out my other blog,
Posted in Application Security. Tagged with , .

One Response

Leave a Reply

Your email address will not be published. Required fields are marked *