California Cybersecurity Audit: What Must Microsoft 365 Evidence?

Counsel has told the IT Director that the company probably meets the thresholds and that the first audit period opens January 1, 2027, and then left the tenant-side questions to the team that runs Microsoft 365 and Entra ID. Three things can be true and undefended at that point: multi-factor authentication is enforced but not phishing-resistant for every population, especially the contractors and service providers who sign in as guests; sign-in and audit records roll off well before an auditor sits down to sample January 2027; and the team that built the controls is the team internal audit expects to assist with the audit, which the regulation forbids for the components that team built. This checklist sets out what the tenant needs to already be recording when the period opens, what the regulation requires (never what it takes to “pass”), and where the determination belongs to counsel, the executive team and the auditor.

Under section 7120(a) of the Agency’s regulations, in force since January 1, 2026 and approved by the Office of Administrative Law on September 22, 2025: “Every business whose processing of consumers’ personal information presents significant risk to consumers’ security as set forth in subsection (b) must complete a cybersecurity audit.” Section 7120(b) sets two routes to “significant risk”: a business meets the revenue threshold in Civil Code section 1798.140, subdivision (d)(1)(C) (deriving 50 percent or more of its annual revenue from selling or sharing personal information), in the preceding calendar year; or it meets the revenue threshold in subdivision (d)(1)(A) and, in the preceding calendar year, processed the personal information of 250,000 or more consumers or households, or the sensitive personal information of 50,000 or more consumers. Civil Code section 1798.140 sets that revenue threshold at annual gross revenues “in excess of twenty-five million dollars ($25,000,000) in the preceding calendar year, as adjusted” under the statute’s own adjustment provision; this checklist states the threshold as the statute writes it and does not state the adjusted figure.

Once a business is in, the first report’s due date and audit period turn on 2026 revenue, under section 7121(a): a business whose 2026 annual gross revenue was more than $100,000,000 must complete its first report by April 1, 2028, for an audit period that runs from January 1, 2027 through January 1, 2028; a business whose 2027 revenue was between $50,000,000 and $100,000,000 reports by April 1, 2029; a business whose 2028 revenue was less than $50,000,000 reports by April 1, 2030. After that first report, section 7121(b) requires a cybersecurity audit covering the next 12 months, every year.

Two facts change the count, stated descriptively and never as a determination for a specific business. Civil Code section 1798.145 says the CCPA “shall not apply to personal information collected, processed, sold, or disclosed subject to the federal Gramm-Leach-Bliley Act (Public Law 106-102), and implementing regulations”, so a bank’s data that is subject to GLBA may narrow the personal information counted toward the thresholds. The same section’s employee and job-applicant exemption states: “This subdivision shall become inoperative on January 1, 2023.” So employee and contractor personal information has counted toward the CCPA since that date, including for this audit. Neither point decides a specific company’s status: have counsel make the applicability and revenue-band call in writing before January 1, 2027, and record which data sets were counted and which were treated as data collected subject to GLBA.

Section 7122(a) requires the audit to be completed “using a qualified, objective, independent professional (“auditor”)” and states: “The auditor may be internal or external to the business.” Independence is defined by conduct, not by employment: the same section states that “the auditor must not participate in business activities that the auditor may assess in the current or subsequent cybersecurity audits, including developing procedures, preparing the business’s documents, making recommendations regarding the business’s cybersecurity program (separate from articulating audit findings), or implementing or maintaining the business’s cybersecurity program.” That line reaches the people and firms who configure Microsoft 365 and Entra ID controls: whoever designs the Conditional Access policies, the Privileged Identity Management roles or the audit log retention settings cannot also be the auditor who assesses those same components.

Section 7122(d) reinforces the point from the evidence side: “No finding of any cybersecurity audit may rely primarily on assertions or attestations by the business’s management.” It adds: “Cybersecurity audit findings must rely primarily upon the specific evidence (including documents reviewed, sampling and testing performed, and interviews conducted) that the auditor deems appropriate.” Under section 7122(f), the report goes to “a member of the business’s executive management team who has direct responsibility for the business’s cybersecurity program,” and that same executive team certifies completion, under penalty of perjury, including a statement that “the business has not made any attempt to influence the auditor’s decisions or assessments regarding the cybersecurity audit.” Decide now, in the project plan and the statement of work, who configures each Microsoft 365 and Entra ID component and who audits it, and keep the two apart. Which type of professional to use, and who performs the audit, is a decision for the business and its counsel; this checklist states the independence rule, not a recommendation of who should hold either role.

Section 7123(c)(1)(A) lists, among the components the audit assesses “if applicable” under section 7123(c): “Multi-factor authentication (including multi-factor authentication that is resistant to phishing attacks for employees, independent contractors, and any other personnel, service providers, and contractors)”. That population list can be wider than a tenant’s MFA policies reach on the day they are written. Microsoft’s Conditional Access authentication strengths page states: “They can choose from three built-in authentication strengths: Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength,” and that “Built-in authentication strengths are always available and can’t be modified.” Microsoft’s own recommendation, in Get started with phishing-resistant passwordless authentication deployment in Microsoft Entra ID, is to move “to phishing-resistant passwordless in your authentication solution.”

Contractors and service providers can reach a Microsoft 365 tenant as guests, not as internal employees, and their authentication strength is a separate policy question. Microsoft’s Authentication and Conditional Access for External ID page states: “When no trust settings are configured and MFA is required, B2B collaboration users are prompted for MFA,” which is a base MFA prompt, not by itself the phishing-resistant strength section 7123(c)(1)(A) names for “any other personnel, service providers, and contractors.” Every population that can reach personal information, employees, independent contractors, other personnel, service providers and guest contractors alike, needs its own authentication-strength policy or a documented exception. Microsoft’s Require multifactor authentication for all users page lists the exceptions it recommends excluding from a blanket MFA policy: “Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration,” and “Service accounts are noninteractive accounts that aren’t tied to any specific user.” Those two categories are exactly what an auditor will ask about separately: document each emergency-access and service account and why it is excluded, rather than leaving it silently outside the policy.

The order in which an organization rolls out phishing-resistant passwordless authentication, and how it handles account recovery during that rollout, is a separate implementation decision this checklist does not walk through. For the MFA baseline itself under a different federal framework, see MFA and NIST SP 800-53: Your Baseline Decides, Not the Catalog.

Section 7123(c)(3)(B) names, as a component the audit assesses: “Restricting the number of privileged accounts, restricting those privileged accounts’ access functions to only those necessary to perform the account-holder’s job, restricting the use of privileged accounts to when they are necessary to perform functions, and using a privileged-access management solution (e.g., to ensure just-in-time temporary assignment of privileged access).” Section 7123(c)(3)(A) adds “revoking their privileges and access when their job functions no longer require them, including when their employment or contract is terminated.”

Microsoft’s answer to just-in-time privileged access in a Microsoft 365 and Entra ID tenant is Privileged Identity Management. Microsoft’s What is Microsoft Entra Privileged Identity Management? page states: “Organizations can give users just-in-time privileged access to Azure and Microsoft Entra resources and can oversee what those users are doing with their privileged access.” Revocation on role change and termination, and the standing count of who holds privileged access, is what Microsoft’s access reviews check on a schedule. Microsoft’s What are access reviews? page states: “User access can be reviewed regularly to make sure only the right people have continued access,” and warns plainly that “Excessive access rights can also lead to audit findings as they indicate a lack of control over access.” Count privileged accounts, move standing role assignments to eligible just-in-time assignments, run access reviews on a schedule for the groups and applications that reach personal information, and keep the activation history and review results for the whole audit period; that history is the evidence the audit looks for under section 7122(d), not a policy document describing the intent.

Section 7123(c)(7) names, as a component the audit assesses: “Audit-log management, including the centralized storage, retention, and monitoring of logs.” The regulation names the requirement without naming a retention period. Microsoft’s Manage audit log retention policies page states that Audit (Premium)’s default audit log retention policy “retains all Exchange Online, SharePoint, OneDrive, and Microsoft Entra audit records for one year,” but that “If you have non-E5 users or guest users in your organization, their corresponding audit records are retained for 180 days”; Audit (Standard) itself keeps records for 180 days flat, and “Audit (Standard) logs generated on or after October 17, 2023 follow the new default retention of 180 days.” The same page states that audit logs can be retained “for up to 10 years” with a separate license, naming the license only as Microsoft’s page names it.

This checklist’s own reading, labelled as such and never as the regulation’s or Microsoft’s words: an audit period that, under section 7121(a)(1), opens January 1, 2027 and is reported on by April 1, 2028 spans about 15 months. Records subject to the Manage audit log retention policies page’s flat 180-day Audit (Standard) retention, which applies to every user regardless of license, will already be gone for most of that period by the time an auditor sits down in early 2028 to sample January 2027. Setting audit log retention for the workloads and users that touch personal information to cover the period plus the reporting window, before January 1, 2027, and proving that policy with its export, is what keeps the evidence available when the audit happens. Exporting and retaining Entra audit and sign-in logs beyond Microsoft’s platform defaults, including where that evidence is stored, is a separate implementation question this checklist does not walk through.

Section 7123(c)(4)(A) names, as a component: “the classification and tagging of personal information (e.g., how personal information is tagged and how those tags are used to control the use and disclosure of personal information).” Section 7123(c)(2) names: “Encryption of personal information, at rest and in transit.”

Microsoft’s platform encryption is Microsoft’s evidence to give, not the tenant’s. Microsoft’s Encryption page states: “With Microsoft 365, your data is encrypted at rest and in transit, using several strong encryption protocols, and technologies that include Transport Layer Security/Secure Sockets Layer (TLS/SSL), Internet Protocol Security (IPSec), and Advanced Encryption Standard (AES).” Which data in the tenant is personal information, and how it is labelled and protected, stays the customer’s own responsibility: Microsoft’s Shared responsibility in the cloud page states that “Regardless of the type of deployment, you always retain the following responsibilities,” including that “You’re responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements.” The mechanism for that classification and control in Microsoft 365 is sensitivity labels: Microsoft’s Learn about sensitivity labels page states that “Sensitivity labels from Microsoft Purview Information Protection let you classify and protect your organization’s data, while making sure that user productivity and their ability to collaborate isn’t hindered.” Map where personal information lives across the Microsoft 365 tenant, label those stores, and keep the label and data-loss-prevention policy exports and their activity reports as the evidence for this component.

Under section 7123(b)(2), the audit assesses “Each of the components of a cybersecurity program listed in subsection (c) that the auditor deems applicable to the business’s information system,” not every component automatically. Section 7123(e) requires the report to “Identify and describe in detail the status of any gaps or weaknesses” and to “Document the business’s plan to address the gaps and weaknesses identified and described pursuant to subsection (e)(3), including the timeframe in which it will resolve them.” Running a tenant gap read against the section 7123(c) components before January 1, 2027 means the gaps the auditor records already carry a remediation date, rather than arriving as a surprise in the report.

An existing audit is not automatically wasted work. Section 7123(f) states: “A business may utilize a cybersecurity audit, assessment, or evaluation that it has prepared for another purpose, provided that it meets all of the requirements of this Article, either on its own or through supplementation,” and gives its own example: “a business may have engaged in an audit that uses the National Institute of Standards and Technology Cybersecurity Framework 2.0 and meets all of the requirements of this Article.” What a NIST CSF 2.0 assessment inside Microsoft Purview Compliance Manager covers, and how its board profile is built, is a separate question this checklist does not walk through.

• If the business does not meet the thresholds in section 7120, the audit does not apply; that determination belongs to counsel.
• If 2026 revenue was under $100,000,000, the first audit period opens later, under section 7121(a)(2) or (a)(3); this is planning time, not an emergency.
• If most of the personal information in the tenant is data collected subject to the Gramm-Leach-Bliley Act, the in-scope set under Civil Code section 1798.145 may be small; that is a legal determination, not a tenant-configuration one.
• If the question is answering a consumer’s own access, deletion or correction request from Microsoft 365, that is a separate duty from a cybersecurity audit, addressed elsewhere.
• If most of the personal information in scope lives outside Microsoft 365, in core banking, ERP or program systems, the tenant evidence in this checklist is only part of the audit.
• If the question is which type of professional or firm to hire as the auditor, or which compliance tool to buy, this checklist does not answer it: section 7122(a) sets criteria, not a shortlist.
• Article 10’s risk assessment submissions and the regulation’s automated decisionmaking technology rules are separate duties in the same regulation, with their own timelines, and this checklist does not address them.
• Another regulator’s annual certification requirement is a separate regime from this one, and this checklist does not address it.

• Ask them to show each section 7123(c) component the tenant touches and the specific Microsoft 365 or Entra ID control and evidence export behind it.
• Ask them to show every population that signs in, employees, independent contractors, other personnel, service providers and guest contractors, and the authentication strength or documented exception for each.
• Ask them to show privileged-role counts before and after the engagement and the just-in-time settings behind them.
• Ask them to show the audit log retention policy and the date the oldest record from the period will expire under it.
• Ask them to show the sensitivity label and data-loss-prevention policies over the stores that hold personal information.
• Ask them to hand the finished configuration and its evidence exports to the internal team to run, with no ongoing managed-service arrangement attached.
• Ask them to confirm in writing that they will not be the business’s auditor for any component they configured, under section 7122(a)(2).

i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and evidences it continuously rather than reconstructing it at audit. The work is a project with an end date: mapping the section 7123(c) components a business expects to be assessed onto Microsoft 365 and Entra ID, configuring authentication strengths, Privileged Identity Management, access reviews, sensitivity labels and audit log retention, and leaving the evidence exports for the business’s own auditor to review, with embedded specialists where the internal team needs more hands for a period. i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and leaves an audit-defensible record. On a related CMMC Level 2 engagement, i3solutions took ownership of the control architecture against AC.L2-3.1.1 and the audit-log design against AU.L2-3.3.1 and delivered the evidence the C3PAO required. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in. Under section 7122(a)(2), the firm that configures a tenant’s controls cannot also audit them, and i3solutions works only on the implementing side of that line: it never performs, certifies or recommends the independent audit itself. This work sits within i3solutions’ Embedding Governance into How the Enterprise Operates and Scales.