Skip to main content

Already a client? Log in

Common engagements

Preparing for an audit

Audits for an investor, for going public or after an incident. Where the work starts, what auditors ask for and what you end up with.

“Producing manual artifacts turns hours into days and days into weeks.”

The situation

There are a few common reasons a company needs an identity expert for an audit:

  • An investor, like private equity, is requiring a systems audit before putting money in.
  • You're getting ready to go public and have brought in a professional services firm to help. Someone needs to work between your system owners and the firm performing the audit.
  • There's been an incident, and now all of your systems need to be evaluated.

Audits are typically focused on a particular set of criteria the auditor is looking for, so knowing that up front helps.

How we approach it

An audit is really a three-way effort:

  • The auditor, who has a particular focus on what they're auditing.
  • Your security and systems people, who provide access to the systems and answer the questions that need local or integrated knowledge.
  • An identity expert, who translates between the auditor and your security and systems people and helps smooth the process between the auditor and your engineers.

Once the auditor gets involved, they set the pace and direction of the audit and guide you toward what they're looking for. You want to be very specific about the evidence you give them.

  1. Find out what the audit is focused on. We start with your security advisor to learn whether the audit covers a particular system or is a general look at access control and governance.
  2. Identify the systems in scope. From there, we identify which systems fall under the audit.
  3. Sit down with the system owners. We go over each system's identity and security posture today, what's likely to trip up a third-party audit and what can be done in the near term to mitigate any known risks.
  4. Get the logs and artifacts in order. We find the systems that produce reliable, immutable logs auditors can use, which makes the process go much smoother. For systems that can't, we either get their logs and artifacts sent to the right place or line up people to provide what the auditors need.
  5. Mitigate as risks come up. When the auditor identifies a risk, the work shifts to mitigation response. That's where it helps to have an architect in the room working out what engineering solutions are possible with what applications and systems you have today.

The takeaway

When the audit is done, every risk it identified has a technical or architectural response for how to mitigate it, built around what your business already has.

You also end up with an architected roadmap based on the findings. If the audit gave you a window to fix something, like a set number of months, the roadmap covers it.

Where it gets complicated

When there aren't systems in place that can serve as trusted repositories for audit logs, it becomes a grind of producing manual artifacts. That typically turns hours into days and days into weeks.

The other place is attempting mitigation on the fly. That's when you get a war room together with engineers and solution experts to work out emergency changes and answers for the auditor.

That's a good time to have someone who has a wide depth of experience from similar engagements, offering guidance and suggestions to your team members.

Get in touch

Sound like your situation?

Send a few lines about what you are dealing with and what is coming up, and we will look at where to start.