This starts you on the long road of trying to figure out what the significance of a finding really is and explaining it adequately to the system administrator. Next, you have to explain this to the business people, who always confuse the matter with asking what business processes the system, and the vulnerability in particular, actually affect. This in turn requires an understanding of the business, how they make their money, how the system you are auditing contributes to this, and how the vulnerability affects this.

Today, I had worked out the final step; testing controls relevant to the business processes. What I mean by this, is that beyond all of the default hardening steps e.g. give administrators complex passwords, which will *always* be applicable, there are a set of controls that are only obvious once you understand what the system is being used for. This is different from understanding how the failure of a default control affects the business, but rather its necessity is dictated and dependent on the business process, and as such, its failure almost self-describes the risk to the business.

For example, if you are reviewing a stock ordering system that has a two step process, namely, one person places an order and the other approves it. Then checking if it is possible to both place and approve an order is one such test. This may be achieved through a variety of technical means ranging from XSS to a full DB compromise, but the actual control you are testing is that separation of duties exists, and that someone can't place themselves on both sides of the transaction.

If you've ever been a financial auditor, you're probably thinking "duh", but for us techies, this isn't the most obvious path.