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.

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.