And Now For Something Completely Different

Last month I asked some friends to come up with a title for the monthly post of topics outside the normal focus of the blog. One of them gave me the idea of naming it “And Now For Something Completely Different”, which is taken from Monty Python’s Flying Circus, or so I’m told. I liked the idea, but should also note I didn’t know where the phrase came from and never actually watched the show outside of a few skits on YouTube. Feel free to use that against me. 😀

WordPress

Let’s start things off with a topic related to this blog and millions of sites on the interweb. A WordPress vulnerability was found in the wild affecting versions 6.9.0 through 6.9.4, and 7.0.0 to 7.0.1. The vulnerabilities affect self-hosed WordPress.org sites, not sites hosted by WordPress.com.

I self-hosted my personal blog for a while, leasing server space with GoDaddy, but then transferred it to WordPress.com in 2012. Self-hosting was fun for a while as it allowed me to make unlimited changes to the look and feel of the site, without restrictions. It also put me in a position to learn a little more about how things work on the backend, but as life got busy it just turned into more of a hassle. It was worth moving to a hosted site with WordPress.com for its ease of use.

With that said, if you’re using a self-hosted .org site and don’t have it set to automatically update, you should do that now.

https://techcrunch.com/2026/07/20/hackers-are-exploiting-recently-patched-wordpress-bugs-putting-millions-of-websites-at-risk

Click to Pray

Bob the Hacker posted another doozy this month related to the Click to Pray app. Click to Pray is the Pope’s official prayer app launched in 2018 that does the things you would think it would do. However, Bob found a vulnerability that made Personally Identifiable Information (PII) available to anyone. He notified various powers that be about the vulnerability during January 2026, but never received a response and it didn’t get fixed. That is, it wasn’t fixed until he posted about it earlier this month. Again, he received no response about the fix, only finding out it was fixed after reading about it online.

https://bobdahacker.com/blog/click-to-pray

META

The more Meta pushes to expand their use of AI, and that doesn’t even include their “glasses”, the more I want to delete all my Meta accounts. As I noted last month, I still have a Facebook account to keep up with things going on in my community / neighborhood and also still have a IG account. The IG account is set to private, limiting it to only friends / contacts I’ve approved, which is a pretty small group. The last picture I posted there was in 2022. There’s still a high probability I’ll delete both FB and IG accounts at some point.

Meta announced they were going to start using pictures from public IG accounts as a basis for other users to create alternate pictures with it’s AI image generator and it was going to be automatically turned on for all public accounts, requiring the user to turn it off. In essence, if you weren’t paying attention to the news, you wouldn’t even know it was happening. The public wasn’t having it and they eventually decided to back off their plan.

https://www.androidcentral.com/apps-software/meta/meta-removes-muse-image-ai-from-instagram-after-users-voiced-major-concerns

That’s it for this month.

SOC 1 vs SOC 2 – Key Differences

In my first post back on June 1ˢᵗ, I posted a brief overview of the System and Organization Controls (SOC) 1, 2, and 3 reports. It acted as a starting point for the GRC blog. Then, on June 25ᵗʰ, I posted a more detailed description of the SOC 2 Trust Services Principles / Criteria (TSC).

Since then, the posts have mostly been from the SOC 1 perspective, although the concepts still mostly apply to SOC 2 reports. With that in mind, I think it would be beneficial have a single post dedicated to detailing the primary differences between SOC 1 and SOC 2 examinations / reports.

There are 3 primary differences between SOC 1 and SOC 2 reports.

Report Driver and Inherent Limitations

SOC 1: An SOC 1 report is typically triggered by clients interested in the financial statement impact of the services provided by the service organization and is geared towards the client’s financial statement auditors. The report opinion includes a section on inherent limitations indicating the report was prepared to meet the needs of a broad range of users (customers) and their auditors who audit user entities financial statements, as noted in the report opinion template below.

The description is prepared to meet the common needs of a broad range of user entities and their auditors who audit and report on user entities’ financial statements and may not, therefore, include every aspect of the system that each individual user entity may consider important in its own particular environment.

SOC 2: An SOC 2 report is typically triggered by clients interested in the protection of data with information that is geared towards IT, security, and compliance personnel at the user entity. The report opinion includes similar language in a section on inherent limitations, indicating it was prepared to meet the needs of a broad range of users (customers), but omits references to it being limited to just their auditors.

The description is prepared to meet the common needs of a broad range of report users and may not, therefore, include every aspect of the system that each individual user may consider important to meet their informational needs.

Control Objectives

SOC 1: The control objectives and supporting controls included in an SOC 1 report are tailored by the service organization. In essence, it’s based on what the service organization thinks their clients would be interested in based on prior communications, contractual terms, or industry standards.

SOC 2: The objectives (criteria) included in an SOC 2 report follow the 5 TSCs, all or in part. The service organization can choose to include just the Common Criteria (Security) in their report or include 1 of more of the 4 remaining TSCs. However, within each chosen TSC, there’s no wiggle room on which objectives (criteria) are included.

Distribution and Restrictions:

SOC 1: SOC 1 reports tend to include limited confidential information, allowing the distribution of them to be less restrictive by the service organization, even though they’re technically geared to their customers financial statement auditors. It’s not uncommon for service organizations to use SOC 1 reports as marketing material, even though that’s not the intended purpose. Included below is the report restriction template from the opinion.

This report, including the description of tests of controls and results thereof in Section IV, is intended solely for the information and use of the Trikomo Payroll, user entities of Trikomo Payroll’s Payroll Processing System during some or all of the period October 1, 2024, to September 30, 2025, and their auditors who audit and report on such user entities’ financial statements or internal control over financial reporting and have a sufficient understanding to consider it, along with other information, including information about controls implemented by user entities themselves, when assessing the risks of material misstatement of user entities’ financial statements. This report is not intended to be, and should not be, used by anyone other than these specified parties.

SOC 2: SOC 2 reports tend to include more confidential information, which lends them to be more restricted in their distribution by the service organization. However, the temptable language in the opinion expands on the topic of who should be interesting in the report to include user entities, business partners, and regulators, among others.

This report, including the description of tests of controls and results thereof in Section IV, is intended solely for the information and use of Trikomo Payroll, user entities of Trikomo Payroll’s Payroll Processing System during some or all of the period October 1, 2024 to September 30, 2025, business partners of the Trikomo Payroll subject to risks arising from interactions with the System, practitioners providing services to such user entities and business partners, prospective user entities and business partners, and regulators. This report is not intended to be and should not be used by anyone other than the specified parties.

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.