Every PHP installation that serves web requests has been open to unauthenticated remote code execution since 2004. On October 21, 2026, the PHP project shipped the fix, the NSA told organizations to take unpatchable systems offline, and four European governments pulled their own websites to patch. Your security team is handling the interpreter. This article is for the person who has to explain the response to an auditor. php2shell is a security incident, and it’s also a live test of the vulnerability management, asset inventory, incident response and vendor management controls you attested to in your last audit. Every framework Axipro works with has a specific expectation for what you do in the next 72 hours and what evidence you keep. Below is the mapping, framework by framework: the control reference, what you need to do, and the artifact that satisfies it. What php2shell Is, in One Minute Two flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0, let an unauthenticated attacker run code on the server. The first is triggered through out-of-memory handling that interrupts PHP while request data is only partially initialized. The second exploits request-owned internal state that survives after its memory has
On October 19, 2026, the AICPA and the Artificial Intelligence Underwriting Company (AIUC) announced a joint assurance offering that bundles a SOC 2 report with an AIUC-1 certification in one CPA-led engagement. A few CPA firms are already running pilots. The full launch is set for early 2027. If you sell AI agents into enterprises, this one’s about you. SOC 2 is the report your prospects already ask for in procurement. AIUC-1 is the standard that checks whether your agent can be talked into leaking data, inventing a refund policy, or calling an API it was never supposed to touch. Putting both into one engagement, under the AICPA’s attestation standards, changes what audit-ready means for any company whose software acts inside other people’s systems. Here’s what was announced, what AIUC-1 tests, why the AICPA’s name matters more than the certificate itself, and what you should do about it if you’re working on SOC 2 or ISO 42001 right now. What the AICPA and AIUC Announced The offering is a single report from one engagement led by a licensed CPA. It combines two things. The first is a standard SOC 2 examination under the AICPA Attestation Standards, with an opinion on
Your managed service provider will show up in your SOC 2 audit whether you plan for it or not. The moment an MSP administers your endpoints, identities, backups, or monitoring, those become your controls operated by someone else’s staff, and your auditor will test them as such. Outsourcing the work never outsources the accountability. That makes MSP selection one of the most consequential decisions a company takes before pursuing SOC 2 compliance or ISO 27001 certification. The right provider shortens your audit, hands over evidence on request, and operates controls you would otherwise have to build yourself. The wrong one turns every evidence request into a negotiation and every finding into a finger-pointing exercise. Here’s what to evaluate before you sign. Understanding the MSP’s Role in SOC 2 and ISO 27001 Compliance How MSPs Impact Your Compliance Posture An MSP typically touches more of your control environment than any other vendor. Access provisioning, patching, endpoint protection, backups, log monitoring, incident response: in a typical growth-stage setup, the provider operates most of the controls an auditor will test. In SOC 2 terms, the MSP is a significant vendor or subservice organization whose work directly affects your Trust Services Criteria. Under ISO
A SOC 2 auditor will not accept a business continuity plan that has never been tested. The AICPA Trust Services Criteria require you to test your recovery procedures, and a written plan sitting in a shared drive does not count. A BCDR tabletop exercise, a facilitated discussion where your team walks through a simulated disaster and makes the decisions a real incident would demand, is the most practical way for a lean team to produce that evidence. This playbook takes a first-time GRC lead from zero to a completed, documented, audit-ready tabletop exercise in three weeks. It covers which Trust Services Criteria the exercise maps to, how to design a realistic scenario, how to run the session, and exactly which artifacts to hand your SOC 2 auditor. No prior exercise experience is assumed, and no external facilitator is required, though we will be honest about when hiring one makes sense. The stakes are real. An untested disaster recovery plan is one of the most common sources of exceptions in SOC 2 reports that include the Availability category. The fix costs one afternoon of your team’s time plus the preparation around it. Few controls offer a better ratio of audit value
Gartner predicts that by 2028, 90% of enterprise software engineers will use AI code assistants, up from less than 14% in early 2024. SOC 2 and ISO 27001 change management controls were written before that shift, and both rest on an assumption that AI-generated code breaks outright: the person who approved a change wrote it, or at least fully understood it. Neither the AICPA nor ISO has published AI-specific change management requirements, so auditors apply the existing controls, SOC 2 CC8.1 and ISO 27001 Annex A 8.32, to commits no human authored. Most teams discover the mismatch mid-audit, when a sample pulls up a 2,000-line agent-generated pull request that was approved in four minutes. This guide maps AI code generation to both frameworks: what each one requires, the risks AI coding assistants introduce, the workflow that satisfies auditors, and the evidence they request when GitHub Copilot, Cursor, or Claude Code shows up in your SDLC. Why AI-Generated Code Breaks Traditional Change Management Change management controls assume a human bottleneck. AI removes it in three places at once. The Volume Problem: AI Commits at Machine Speed A single developer running an agentic coding tool can open more pull requests in a
SOC 2 has no fixed evidence retention period. The AICPA doesn’t tell service organizations to keep evidence for one year, three years, or seven. What it does require is proof that every in-scope control operated across the entire audit period. That’s stricter than it sounds, because a log that expires before your auditor samples it is a control you can no longer prove. That makes evidence retention one of the few SOC 2 topics where a configuration default can cost you a clean report. Below, we walk through what the AICPA and the Trust Services Criteria require and how long to keep each type of evidence. We also cover where HIPAA, PCI DSS, ISO 27001, and GDPR change the answer, and how to store and automate evidence so it holds up when the auditor tests it. For most SaaS teams, the short answer is this. Keep evidence for the current observation period plus at least one prior period, and keep security logs searchable for 12 months. Go longer only when a contract, a regulation, or a legal hold says you have to. What Is SOC 2 Evidence Retention vs. Data Retention: Key Distinctions Teams often lump the two into one
You can get a SaaS company ready for a SOC 2 audit in six weeks, but you’ll feel every one of them. Most published timelines say three to six months. For a company with no project owner, no identity provider, and nothing written down, that’s about right. A cloud-native startup that already has the basics in place and can protect some time is a different story, and it can fit the work into six hard weeks. This plan walks through that route one week at a time. Each week has an owner, an hour estimate, and a clear test for when it’s finished. The free Google Sheet version turns the plan into a tracker you can hand out to owners and update in your weekly standup. Before you start, know what you’re signing up for. At the end of week 6 you’ll be audit-ready, which isn’t the same as holding a Type II report. Nobody can get you a Type II in six weeks. This is also the do-it-yourself route, and it takes a lot of hours. We’ll show you where those hours go and what the faster option looks like. Is Six Weeks Realistic for Your Company? Six weeks
An AI agent reads a customer record, decides a refund is warranted, and calls the payments API. The trail it leaves looks nothing like a human doing the same job. The log says a user logged in, a service account made three API calls, and the transaction cleared. It doesn’t say why the agent decided on a refund, what it read first, which model version did the reasoning, or who gave the agent permission to act in the first place. That missing “why” is the whole audit problem. This article covers what ISO/IEC 42001:2023 and the SOC 2 Trust Services Criteria expect from AI agent audit logs, where the two overlap, the fields a log needs to satisfy both, how long to keep records, what you shouldn’t record, and how to package it all for an auditor. It’s written for the CTO, platform lead, or founder who owns compliance for a product that now ships with autonomous agents and needs a certification and a Type II report without running two separate logging programs. The Compliance Gap: Traditional Application Logs vs. AI Agent Audit Logs Why Standard Logs Fall Short for Autonomous Agents Application logs were built for deterministic software. Same
