How we work
Methodology
The same shape on every assurance engagement, scaled to the scope. Six stages, four principles, and a quality gate before anything leaves the building.
Four principles that shape everything else
Most audit methodologies read identically because most are describing the same standards. What separates a defensible file from a weak one is a small number of practices that are easy to state and awkward to actually do.
1. Scope is agreed in writing, including exclusions
Every engagement begins with a written scope naming the areas, systems, entities and period under review — and, just as explicitly, what is not covered.
An unbounded scope cannot be defended and cannot be priced. More importantly, a conclusion drawn from a narrow scope but written as though it were broad is exactly the kind of thing that fails an external quality review. Our reports state their boundary plainly, including where we chose not to look and why.
The six stages
2. Population completeness is established independently
This is the practice that most separates a reliable audit from a superficial one, and it is worth understanding even if you never commission us.
If an auditor samples twenty-five changes from a list that management extracted for them, they have tested twenty-five changes from a list. They have no basis to conclude anything about changes that never appeared on it. The sample is only meaningful if the population it came from is provably complete.
We establish completeness independently before drawing any sample — reconciling the change log to the production deployment record, the user list to the directory service, the transaction population to the general ledger. Ask any firm bidding for your audit how they do this. The answer is diagnostic.
3. Design effectiveness before operating effectiveness
These are separate tests and both are necessary. A control can be diligently performed and still useless — a monthly access review covering only active employees will never find the contractor account left enabled after the contract ended.
Design testing asks whether the control, as specified, would address the risk. Operating effectiveness asks whether it actually happened, consistently, across the period. Testing operating effectiveness on a control with a design flaw wastes the budget and produces a finding that misdirects remediation.
4. No surprises at closing
Every exception is put back to the control owner with the evidence attached before it becomes a finding. Sometimes the exception dissolves — there was a compensating control, or a system quirk we misread, or the evidence exists somewhere we did not look.
That conversation happens during fieldwork, not at the closing meeting. A closing meeting where management first learns of a finding is a failure of process, and it damages the relationship the report depends on.
The six stages
Every assurance engagement follows the same shape. A five-day targeted review and a forty-day regulatory assessment differ in depth, not in structure.
Standards we work to
Engagements are conducted in accordance with ISACA's ITAF, the IT audit and assurance framework. Each engagement also references its subject-matter framework — COBIT 2019 for governance, ISO/IEC 27001:2022 for information security management, ISO 22301:2019 for continuity, NIST CSF 2.0 for cyber programme structure, OWASP ASVS and the OWASP Testing Guide for application security, or the specific regulation where one governs.
Where we work alongside an internal audit function we align to the IIA Global Internal Audit Standards, so the work integrates with that function's own quality framework and survives its external quality assessment.
Sampling
Sample sizes follow the assessed risk rating of the control: 25 items for controls rated High or Critical, 10 to 15 for Medium, 5 for Low. Where a population is smaller than the indicated sample we test the full population and record that we did.
Samples are selected from the verified population, not from a convenience extract, and the selection basis is documented so it can be reproduced.
Findings, ratings and root cause
Every finding states the condition, the criteria it fails against, the evidence, the risk in your specific business context, and the root cause.
Root cause is the part most often skipped and the part that determines whether the finding recurs. Twelve unauthorised changes found, twelve retrospectively approved, and the emergency change process that permitted them left untouched — that finding will be back next cycle. Remediation should address the cause, and we assess it on that basis when we follow up.
Independent quality review
Every report is reviewed by a practitioner who did not perform the fieldwork, before it is issued. The reviewer confirms that conclusions are supported by evidence in the working paper file, that findings are rated consistently against the agreed scale, and that the report says what the evidence supports rather than what would be more comfortable to write.
The report names who performed the work and who reviewed it. Accountability should be visible rather than institutional.
What we hand over
The working paper file is yours. Evidence references, test procedures, samples, conclusions — retained and available if your external auditor or a regulator asks to inspect it. A report you cannot substantiate afterwards has limited value.
Related
Credentials and accreditations — the certifications behind the methodology, and what we do not claim.
The team — who performs the work and who reviews it.
Free templates — the SBP ETGRM checklist and ISO 27001:2022 gap workbook apply the same rating discipline described above. Use them before commissioning anything.
Frequently asked questions
Need an independent view?
Tell us the scope, the regulator and the deadline. We will come back with an approach, a team and a fee estimate.
Request a proposal