Internal Assessment of Third-Party SOC Reports

The first batch of posts here have been from the perspective of the audit firm performing System and Organization Controls (SOC) examinations. It’s worth taking a step back and looking at things from the perspective of the company receiving an SOC report as part of their third-party risk management (TPRM) process.

An important aspect of Governance, Risk, and Compliance (GRC) is ensuring third-party service providers maintain appropriate internal controls. This has become even more relevant as companies outsource services so they can focus on their core competencies. For example, using the example company in prior posts, Trikomo Payroll would focus on payroll processing and outsource data center facilities and network operations for their systems to a third-party managed services provider. Sticking with creating company names using references to Greece, let’s name this data center managed service provider Acropolis Web Services (AWS). Is that acronym too on the nose?

Trikomo Payroll would need to consider and assess risks related to outsourcing to AWS. From that perspective, Trikomo Payroll would implement a periodic (annual) control to review AWS internal controls. This can be in the form of an Internal Controls Questionnaire (ICQ). Typically, however, AWS will respond by providing their SOC 1 and/or 2 report, which they had completed by an independent audit firm as a proactive measure to limit the time and resources required to complete individual ICQs for each of their clients.

At this point, legal, security, and/or compliance personnel will need to know what to look for when reviewing the AWS SOC report(s). Included below is a list of items they’ll want to look for:

General / Opinion

  • Is the audit firm that performed the SOC examination reputable?
  • Are services used by Trikomo Payroll covered by the report?
  • Is the period covered by the report appropriate?
  • Was there a “clean” opinion or was it qualified?

The AICPA has an online tool that can be used to search for the firm to ensure they’ve completed a peer review, which is an assessment of the audit firms system of quality control. The tool can be found here –> AICPA Peer Review Program.

Complementary User Entity Controls (CUEC)

  • Reconcile (or map) the CUECs included in the AWS SOC report to internal controls implemented by Trikomo Payroll.
  • Assess the risk for any CUEC’s that Trikomo Payroll do not have complementary controls to mitigate.

AWS would have completed an SOC examination to assess internal control requirements for the vast majority of their clients. As such, the scope of the report, and subsequently one or more of the CUECs, might include services not used by Trikomo Payroll.

Example template for mapping SOC CUECs to internal controls.

Complementary Subservice Organization Controls (CSOC)

  • Determine if AWS used any subservice organizations to provide services relevant to Trikomo Payroll.

Depending on the nature and extent of services outsourced, there might be a need to request the SOC report from the subservice organizations if it’s determined their services are relevant to Trikomo Payroll. However, due to restrictions on report disseminated, it might be difficult to obtain the subservice organization report.

Controls & Test Results

  • Are controls relevant to Trikomo Payroll included in the report?
  • Are there any exceptions noted as a result of testing those controls?
  • Does Trikomo Payroll have internal controls in place to mitigate the risk for any test exceptions noted.

Typically, if exceptions noted in the report didn’t rise to the level of qualifying the control objective (and subsequently the report opinion), the risk to Trikomo Payroll would be limited. However, it’s important to track these exceptions from year-to-year to determine if it’s a recurring issue with the service provider.

The staff performing the assessment will want to document the date the assessment was completed and who completed the assessment as evidence for their auditors. I’ve found the best method for documenting the evidence is to use an internal ticketing system as it creates an electronic record of the assessment having occurred, the evidence (e.g., SOC report, CUEC mapping, etc.) can be attached, the date it was completed, and it doesn’t get lost if there’s personnel turnover.

Emergence of Shadow AI

Shadow IT was a term created to describe the use of technology outside the purview of IT security and compliance teams (security compliance). An example of Shadow IT would be tools like flash drives or cloud storage to share documents with internal/external personnel, which can lead to the loss of sensitive/confidential information. This is why data loss prevention (DLP) measures are an important aspect of security compliance. An example DLP measure would be disabling USB drives on computers to prevent the use of flash drives.

AI is often not being introduced through structured programs with clear ownership and governance.

This brings me to an interesting article I read yesterday related to Shadow AI, which has emerged as a new term during the past few years. I find the concept interesting since, at least from the outside looking in, it appears AI is being pushed from the top down, bypassing attempts by security compliance to introduce controls into processes. This approach often leads to data loss similar to what happened to Meta last month while implementing their Model Compatibility Initiative (MCI) tool, even if the data loss was limited to internal personnel.

This is why security leadership must evolve from the “Department of No” to the “Department of How.”

The writer of the article is of the opinion the security function needs to evolve from “No” to “How”. This brought flashbacks from when companies reimagined internal and external audit teams as advisers. I’m not going to refute the writer here so much as I think this should already exist. Security should already be included in the “how” through project management and software development life cycle processes.

The issue is still that the security compliance teams are being bypassed. Organizations are asking staff to find ways to use AI outside the typical project management and SDLC processes. There’s no reimagining of security compliance if organizations aren’t willing to use a structured approach to implementing AI… and this introduces a massive risk that I don’t think executives and board members are aware of or are just willing to accept to beat the competition.

The CISO vs. Shadow AI Cold War

Just my two cents.

And Now For Something Completely Different

I’m going to take a stab at doing something different on the GRC blog so it doesn’t get too stale by posting links to articles I found interesting during the past month or so and adding some thoughts about the articles. Where the focal point of the blog will mostly revolve around Governance, Risk, and Compliance (GRC), these will likely stray from that focus and into the wider IT industry / environment.

FIFA

This post popped into my feed on the infosec.exchange Mastodon instance and, though it can be a little technical to read at times (read: boring), it might be the most interesting read from the last month. Bob the Hacker was able to find a weakness in FIFA’s Agent Platform that allowed him to not only see the backend of the FIFA feeds, but change them if he wanted. Things got worse as he attempted to contact FIFA to report the security flaw. The headline for the post makes it even better, thinking about how funny it would have been if he changed a match feed to Rick Astley’s Never Gonna Give You Up at the most inopportune time.

I Could’ve Rickrolled the Entire FIFA World Cup. All I Needed Was My ID

On that note, why not give the song a watch/listen.

Apple

It didn’t happen overnight, but the devices I use in my personal life are almost entirely in the Apple ecosystem, so articles about them tend to peak my interest. However, the reality of this article headline about an exploit doesn’t really hold up from a risk perspective. Yes, there’s an exploit on millions of iPhones that can’t be patched. However, assuming the information included in the article is accurate, it only affects older iPhones, requires directly connecting to the iPhone via a special USB device, and doesn’t grant access to user data. It’s not something to dismiss, but maybe don’t let someone connect a USB device to your iPhone without your knowledge.

New Exploit Bypasses Apple’s Boot Defenses

Sticking with the Apple ecosystem, Apple is planning to move from @icloud.com to @private.icloud.com for their hide my email address feature. I’ve used this feature a few times when signing up for an online web site/service. I’m not a fan of the change as it would seem to make it easier for web sites to blacklist @private.icloud.com email addresses, nullifying its usefulness.

Apple Plans to Change its Hide My Email Privacy Feature

META

I don’t actively use Meta platforms much anymore, mostly just using Facebook for the community page to keep up with things happening in my neighborhood, but that’s not really the point of the article. The article is about an employee tracking program called MCI.

Meta rolled out the Model Compatibility Initiative (MCI) tool in April to US employees. The tool “collects computer inputs such as mouse movements, click locations and keystrokes, as well as screen content,” according to workers who have been petitioning against it over privacy, security, and personal liberty concerns.

There are obviously a lot of decisions that go into obtaining employment and deciding to stay with that employer over time, but I’m not sure I’d be willing to give up all my privacy to allow an employer to go into this level of monitoring. To make matters worse, Meta failed to protect the data it was gathering in the program… TWICE. Not good.

Meta Pauses Employee-Tracking Program Following Internal Data Leak

That’s it for this month.