/

  / CMMC Level 1 Requirements: A Complete Guide

CMMC Level 1 Requirements: A Complete Guide

Phase 1 of the Cybersecurity Maturity Model Certification program went live on November 10, 2025. From that date, the Department of Defense can write CMMC requirements directly into new solicitations, and contractors who handle even basic government data cannot win awards without a current CMMC status in the Supplier Performance Risk System (SPRS). For roughly 63 percent of the Defense Industrial Base, that means Level 1: 15 foundational safeguards, an annual self-assessment, and a signed affirmation from a senior official.

Level 1 is the smallest version of CMMC. It is also the one most contractors are about to encounter first, and the one with the highest false-confidence rate. This guide covers every requirement, every assessment objective, and every step from scoping to SPRS submission.

CMMC Level 1 Requirements Guide

What Is CMMC Level 1?

CMMC Level 1 (Foundational) is the entry tier of the Cybersecurity Maturity Model Certification program, codified in 32 CFR Part 170. It requires defense contractors who handle Federal Contract Information (FCI) to implement 15 basic safeguarding practices and to confirm that implementation through an annual self-assessment.

The 15 practices come directly from FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, a clause that has technically applied to federal contractors since 2016. What CMMC added is an assessment methodology and a verification mechanism. Until CMMC, no one was checking whether contractors actually did the 15 things they were contractually obligated to do. Under the final CMMC Program Rule, effective December 16, 2024, that gap is closed.

Earlier CMMC drafts described Level 1 as a 17-practice framework because three physical-protection requirements were listed separately. The final rule consolidates them, and the official count now sits at 15 practices with 17 underlying assessment objectives drawn from NIST SP 800-171A. Both numbers are correct, depending on which level of granularity you are working at.

What Is the Purpose of CMMC Level 1?

The purpose is narrow and specific: to protect FCI from unauthorized disclosure. 

FCI is information the federal government either generates or receives during contract performance that is not intended for public release. Think proposal correspondence, delivery schedules, performance reports, and routine contract communications. None of it is classified. None of it is even particularly sensitive in the traditional sense. But aggregated across thousands of contractors and exposed to adversaries, it gives a meaningful picture of what the U.S. government is buying, from whom, and on what timeline.

Level 1 exists because too much of the Defense Industrial Base was failing to apply even basic hygiene to that data. CMMC Level 1 turns inconsistent expectations into a yearly verification cycle.

CMMC Level 1 Scope

The CMMC Assessment Scope for Level 1 is defined in the official DoD CMMC Level 1 Scoping Guide. It covers every information system that processes, stores, or transmits FCI, along with the people, processes, and physical facilities that interact with those systems.

In practical terms, scope includes workstations and servers that handle FCI, cloud services used to store or transmit FCI, email systems used to send or receive FCI, file-sharing platforms holding FCI documents, network infrastructure carrying FCI traffic, physical facilities where any of the above are located, and personnel with access to any of the above.

Anything that does not touch FCI is out of scope. This is the simplest scoping model in CMMC, and it is also where most contractors trip up. The temptation is to declare a narrow scope (“just the one folder on the file server”) and ignore the email, the laptops, and the backups. Auditors and primes will not accept it.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

CMMC Level 1 Requirements: All 15 Practices Explained

The 15 practices fall across six domains. Each is mapped to a NIST SP 800-171 control identifier, but Level 1 only assesses the subset of objectives relevant to FCI.

Access Control (AC)

AC.L1-B.1.I – Authorized Access Control

Practice: Limit information system access to authorized users, processes acting on behalf of authorized users, or devices.

Maintain a current list of users, processes, and devices authorized to access systems holding FCI. This means active user-account management: unique identifiers for each user, accounts disabled promptly when employment ends, and a documented process for reviewing who has access and why. Shared credentials are not acceptable. This is the foundation every other access control practice is built on, and it is where many contractors have their first reckoning with how loosely their environments have actually been managed.

AC.L1-B.1.II – Transaction and Function Control

Practice: Limit information system access to the types of transactions and functions that authorized users are permitted to execute.

Apply the principle of least privilege. A user with access to read FCI does not automatically get access to delete it, share it externally, or modify system configurations. Role-based access controls (RBAC) satisfy this requirement. In practice, this means auditing what each role can actually do in your systems and trimming permissions down to what is genuinely necessary for the job function.

AC.L1-B.1.III – External Connections

Practice: Verify and control or limit connections to and use of external information systems.

Know what external systems your in-scope environment connects to — cloud storage, partner networks, contractor laptops on home Wi-Fi — and apply controls to those connections. Acceptable Use Policies, VPN requirements, and explicit allow-lists for external sharing all map here. The key word is verify: you need documented evidence that external connections are inventoried and controlled, not just assumed to be fine.

AC.L1-B.1.IV – Control Public Information

Practice: Control information posted or processed on publicly accessible information systems.

Make sure FCI does not end up on your public website, your company blog, or any other publicly accessible system. This is mostly a process control: establish who is allowed to publish to public-facing systems and what review happens before anything goes live. It sounds obvious, but incidents involving inadvertent FCI disclosure through company websites and public repositories are more common than the industry likes to admit.

Identification and Authentication (IA)

IA.L1-B.1.V – Identification

Practice: Identify information system users, processes acting on behalf of users, or devices.

Every user, service account, and device that accesses FCI must have a unique identifier. Shared accounts — the classic “admin” login that three people use — are not acceptable. This applies to human users, automated processes, and devices alike. Document your user inventory and tie every access event to a specific, identifiable entity.

IA.L1-B.1.VI – Authentication

Practice: Authenticate (or verify) the identities of those users, processes, or devices as a prerequisite to allowing access to organizational information systems.

Passwords, multi-factor authentication, certificates, or biometric controls. Level 1 does not mandate MFA the way Level 2 does, but most modern environments implement it as the practical default — and assessors will note when they see environments that do not. Password complexity requirements, account lockout policies, and password reuse restrictions all live under this practice. For a deeper look at how authentication requirements scale across CMMC levels, the CMMC encryption requirements guide covers related technical controls in detail.

Media Protection (MP)

MP.L1-B.1.VII – Media Disposal

Practice: Sanitize or destroy information system media containing FCI before disposal or release for reuse.

When you decommission a hard drive, a USB stick, or a printer with internal storage, you must wipe or destroy it before it leaves your control. NIST SP 800-88 sanitization procedures define what “wiped” means in practice: a quick format is not enough for most media types. Throwing old laptops in a donation bin or the dumpster is an explicit failure of this control, and it is one of the most common findings in Level 1 assessments.

Physical Protection (PE)

PE.L1-B.1.VIII – Limit Physical Access

Practice: Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.

Locked server rooms, badge-access offices, and clean-desk policies. If anyone can walk into your office and sit down at an unlocked workstation holding FCI, you fail this control. Physical access controls need to be commensurate with the environment: a home-based contractor and a 200-person manufacturer have different practical implementations, but the principle is the same.

PE.L1-B.1.IX – Manage Visitors and Physical Access

Practice: Escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices.

This practice combines visitor escort procedures, physical access logging, and management of access devices (badges, keys, smart cards) into a single practice with three assessment objectives. Visitor logs need to be real and current. Badge management needs to include a process for deactivating credentials when employees leave or access needs change.

Worth Knowing: The consolidation of PE.L1-B.1.IX

The consolidation of PE.L1-B.1.IX from three practices into one is why you will see both "17 practices" and "15 practices" in older guidance. The final 32 CFR Part 170 rule confirms the count is 15 practices with 17 assessment objectives. Vendors and consultants who still quote 17 practices are working from outdated drafts.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

System and Communications Protection (SC)

SC.L1-B.1.X – Boundary Protection

Practice: Monitor, control, and protect organizational communications at the external boundaries and key internal boundaries of the information systems.

Firewalls at the network perimeter, network segmentation between trust zones, and monitoring of traffic at boundary points. For a small business, this can be as simple as a properly configured firewall with explicit allow rules and logged traffic. The key requirement is that the boundary is defined, protected, and monitored — not just assumed to exist because you have a router.

SC.L1-B.1.XI – Public-Access System Separation

Practice: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Your public-facing web server should not sit on the same network as your internal file server. Use a DMZ, separate VLANs, or hosted cloud separation to ensure that a compromise of a public system does not give an attacker a direct path into FCI-handling systems. If you have no publicly accessible systems within your assessment scope, this practice can be marked Not Applicable — but document that determination carefully.

System and Information Integrity (SI)

SI.L1-B.1.XII – Flaw Remediation

Practice: Identify, report, and correct information and information system flaws in a timely manner.

Patch management. Operating systems, applications, firmware — all of it. “Timely” is not defined with hard SLA language at Level 1, but assessors expect a documented patching process and evidence that patches are actually being applied, not just scheduled. A two-year-old critical vulnerability sitting unpatched is a finding regardless of what your policy document says.

SI.L1-B.1.XIII – Malicious Code Protection

Practice: Provide protection from malicious code at appropriate locations within organizational information systems.

Endpoint antivirus or EDR, email gateway scanning, and protection at any point where files enter the environment. Cloud-based protection counts, provided it is actually deployed and active on in-scope assets. “We have a license” is not the same as “it is installed and running on every covered endpoint.”

SI.L1-B.1.XIV – Update Malicious Code Protection

Practice: Update malicious code protection mechanisms when new releases are available.

Automatic signature updates and engine updates. The control is about currency, not just deployment. An antivirus product with definitions six months out of date fails this practice, even if the software itself is installed and running. Verify that automatic updates are enabled and confirm through configuration evidence — not assumption.

SI.L1-B.1.XV – System and File Scanning

Practice: Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.

Scheduled full-system scans plus real-time on-access scanning. Most commercial antivirus and EDR products do both by default, but you need evidence that the configuration is enforced across all in-scope endpoints — not just on the machine the IT manager happens to use. Export your endpoint management console settings. That is your evidence.

CMMC Level 1 Compliance Checklist

CMMC Level 1 Compliance Checklist

Before you begin a self-assessment, work through the following steps. This will not certify you, but it will surface most of the problems contractors encounter on their first attempt.

Confirm FCI handling. Identify every contract, vendor relationship, and data flow involving FCI. Review your DoD contracts and subcontracts for FAR 52.204-21 clauses.

Define your assessment scope. Document every system, location, and person that touches FCI. Reference the official CMMC Level 1 Scoping Guide and be prepared to defend every boundary decision.

Inventory your assets. Workstations, servers, cloud accounts, mobile devices, network gear. If it touches FCI, it is in scope and it needs to be listed.

Map controls to systems. For each of the 15 practices, document which technical or administrative measure satisfies it on each in-scope system. The mapping needs to be explicit, not assumed.

Identify your Affirming Official. This must be a senior representative with authority to bind the organization — a CEO, president, or designated corporate officer. An IT manager is not sufficient.

Gather evidence. Screenshots, configuration exports, policy documents, training records, vendor attestations. Evidence must exist before the assessment, not be created afterward.

Run a gap assessment. Self-test each practice. Since no POA&Ms are allowed at Level 1, anything not fully met must be remediated before the formal self-assessment.

Document a basic System Security Plan. Level 1 does not formally require an SSP, but assessors and primes will ask for one, and it becomes mandatory the moment you advance to Level 2. Start it now.

Register for SPRS access. Your Affirming Official needs a Procurement Integrated Enterprise Environment (PIEE) account with the SPRS Cyber Vendor User role.

Submit results and affirmation. Enter your Level 1 self-assessment results in SPRS and have the Affirming Official sign the attestation.

CMMC Level 1 Artifact Retention Requirements

Under 32 CFR 170.15(c)(2), the artifacts used as evidence for your Level 1 self-assessment must be retained for six years from the CMMC Status Date — the date the assessment was completed and entered in SPRS.

Six years matters because the DoD or a prime can ask to inspect your evidence at any point in that window. Refusing or being unable to produce it can trigger contract remedies, including suspension or debarment. The retention requirement also intersects with False Claims Act liability: if the affirmation submitted to SPRS turns out to have been inaccurate, the evidence chain is what gets investigated.

Practical retention covers the completed self-assessment record (objective-by-objective), all evidence cited in MET determinations, the senior-official affirmation signed in SPRS, any supporting policies, screenshots, and configuration exports referenced, and records of the assessment methodology used.

Most contractors store this in a dedicated compliance repository with version control.

Anything less invites a scramble during the next assessment cycle, since some evidence (like firewall rule snapshots) changes constantly and is hard to reconstruct after the fact.

Phased Implementation Timeline and Key Deadlines

CMMC implementation is rolling out in four phases under 32 CFR 170.3(e), on a timeline tied to the publication of the 48 CFR Acquisition Rule.

December 16, 2024: The 32 CFR Part 170 final rule takes effect, codifying CMMC as a federal regulation.

September 10, 2025: The 48 CFR DFARS final rule is published, amending DFARS 252.204-7021 to embed CMMC contract clauses.

November 10, 2025: Phase 1 begins. DoD solicitations can include CMMC Level 1 and Level 2 self-assessment requirements. This is the live enforcement date.

November 10, 2026: Phase 2 begins. Level 2 certification assessments (C3PAO-led) appear in more contracts at DoD discretion.

November 10, 2027: Phase 3 begins. Level 3 certification assessments enter contracts for the most sensitive CUI.

Full implementation is expected approximately three years after Phase 1, at which point all applicable contracts will contain CMMC clauses.

For Level 1 contractors, the operative date is November 10, 2025. From that point forward, a current Level 1 status in SPRS is a precondition for award on covered contracts. You do not get to fix it after the solicitation drops.

CMMC Level 1 Certification Challenges

Most Level 1 failures come from a small set of recurring problems.

Scope creep and scope denial. Contractors either underscope (excluding email, mobile devices, or cloud storage that clearly handles FCI) or overscope (sweeping in systems that have no FCI exposure). Both create problems. Underscoping risks false attestation. Overscoping wastes resources and creates evidence gaps that are hard to defend.

Missing evidence for inherited controls. Many Level 1 environments rely on cloud services (Microsoft 365, Google Workspace, AWS) to satisfy several practices. Inheritance is legitimate, but you need attestations from the provider, and you need to know which controls are inherited versus customer-responsibility. The shared responsibility model is real, and assessors check it.

Documentation that does not match reality. Policies that say one thing while configurations do another. The policy says workstations lock after 15 minutes; the actual Group Policy locks them after 60. Auditors compare written claims to system reality, and discrepancies become NOT MET findings.

Affirming Official confusion. The Affirming Official must be a senior representative with authority to bind the organization. An IT manager is typically not sufficient. A CEO, president, or designated corporate officer is the expected level. Some contractors discover this late in the process when no one in the org chart has the required authority formally documented.

Treating Level 1 as a checkbox. Level 1 is light compared to Level 2, but it is not nothing. The senior-official affirmation creates personal legal exposure, and the False Claims Act applies to false attestations the same way it applies to fraudulent invoices.

Important: The Department of Justice has been explicit that cybersecurity-related False Claims Act cases are an active enforcement priority. A signed CMMC affirmation that overstates compliance is precisely the kind of attestation that has produced multi-million-dollar settlements at other federal agencies. Take the senior-official signature seriously.

What Are the 15 CMMC Level 1 Requirements?

The 15 requirements come from FAR 52.204-21(b)(1) and cover Access Control (4 practices), Identification and Authentication (2), Media Protection (1), Physical Protection (2), System and Communications Protection (2), and System and Information Integrity (4). All 15 practices are described in full in the requirements section above.

Level 1 is self-assessment only. Contractors evaluate their own implementation and submit results to SPRS along with a senior-official affirmation. No C3PAO involvement is required at Level 1. Levels 2 and 3 involve third-party or government assessments depending on the contract type and data sensitivity.

Annually. The self-assessment must be performed every year, and a fresh senior-official affirmation must be submitted to SPRS within 12 months of the prior affirmation. Missing the deadline invalidates your status and makes you ineligible for new covered contract awards.

Noncompliance means loss of eligibility for new DoD contract awards requiring Level 1, potential suspension or termination of existing contracts, exclusion from prime contractor supply chains, and False Claims Act liability for any false attestations already submitted to SPRS.

For a small business with reasonable IT hygiene already in place, two to four weeks of focused effort is typical. For contractors starting from a less mature baseline, two to three months is more realistic. The bottleneck is usually evidence collection and scoping, not technical remediation. A structured gap assessment at the start of the process will give you a realistic timeline for your specific environment.

Yes. CMMC requirements flow down through the supply chain. Any subcontractor handling FCI in performance of a DoD subcontract needs its own current Level 1 status in SPRS. Primes are increasingly requiring proof of CMMC status before subcontract award, and this trend accelerated through 2025.

CMMC Level 1 covers 15 practices drawn from FAR 52.204-21 and addresses FCI only. NIST SP 800-171 contains 110 controls and addresses CUI, mapping to CMMC Level 2. The Level 1 practices are a subset of the broader 800-171 framework, but the two are not equivalent. A contractor compliant with NIST 800-171 is also compliant with Level 1; the reverse is not true. For a detailed breakdown of how the two frameworks compare, see our guide on CMMC vs NIST 800-171.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

Compliance software collects the evidence. A consultant builds the system that evidence is meant to prove. That’s the real difference in the ISO 27001 consultant vs software decision, and most teams only figure it out after they’ve bought one and realized they still need the other. Below, we compare what each route covers, where it breaks down, and what it costs you in time, money, and your team’s hours. Short version: software on its own works for a small group of companies. For most SaaS and tech scale-ups trying to get an enterprise deal over the line, consultant-led implementation on a compliance platform is the faster and safer path to a certificate. Quick Answer: Consultant, Software, or Both? Software-only works if you already have an in-house security lead who’s taken a company through ISO/IEC 27001 before and has the time to own the project. Consultant-only still makes sense if you run mostly on-premise or legacy systems that platforms barely integrate with. For everyone else, which means most cloud-native companies under a few hundred people, a hybrid works best: a platform to handle evidence and monitoring, and a consultant to build the management system and stand behind it in front of an auditor. Here’s why. What an ISO 27001 Consultant Handles ISO/IEC 27001:2022 is a management system standard. Clauses 4 to 10 cover how you run information security, and Annex A lists 93 controls you pick from based on risk. Almost none of it is box-ticking. Most of it comes down to judgment calls about your business, and that’s what you’re paying a consultant for. Scoping, Gap Analysis and Risk Assessment Scope is the first decision you make, and the most expensive one to get wrong. Go too wide and you’ll spend months on controls for systems no customer asks about. Go too narrow and the certificate won’t get through the procurement review it was supposed to pass. A consultant scopes around the deals you’re trying to close, runs a gap analysis, and builds a risk assessment based on your real assets and threats. That’s the document auditors dig into hardest. ISMS Documentation and Policy Writing The standard asks for a specific set of documents: the ISMS scope, information security policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, and evidence of competence, monitoring, internal audit, and management review. A consultant writes these around how your company works day to day, instead of how a template imagines it works. Auditors check whether you follow your own procedures, so a mismatch shows up fast. Internal Audit and Certification Audit Support You need an internal audit before certification, and Clause 9.2 says the auditor has to be objective and impartial. In a small company, the people who built the ISMS can’t credibly audit it, so most teams outsource it through ISO 27001 internal audit services. A good consultant also gets your team ready for the Stage 1 and Stage 2 audits, joins the conversations that matter, and handles corrective actions if the auditor raises nonconformities.  What ISO 27001 Compliance Software Handles Compliance automation platforms, often called GRC platforms, have changed how cloud-native companies get certified. They’re very good at the repetitive, evidence-heavy side of the work. Automated Evidence Collection and Continuous Control Monitoring The platform plugs into your cloud provider, identity provider, code repos, HR system, and device management tools, then pulls evidence on its own. It’ll flag an unencrypted storage bucket, an ex-employee who still has access, or a laptop without disk encryption. For technical controls, that saves weeks of screenshots and spreadsheet tracking. Policy Templates and Annex A Control Mapping Most platforms come with a policy library and map each control to the ISO 27001 clauses and Annex A. You get a starting point and a clear view of which controls have evidence and which don’t. Auditor Access and Ongoing Compliance Tracking Auditors can log in and review evidence themselves, which cuts down fieldwork. After you’re certified, dashboards show when controls slip between surveillance audits, so you aren’t rebuilding evidence from scratch every year. Where Each Approach Falls Short Neither route covers everything by itself. The good news is that the ways each one fails are predictable, so you can plan around them. Limits of Compliance Automation Platforms A platform can tell you a control is failing. It can’t decide your scope, run your risk assessment, write a policy that matches your operations, convince your CTO to change the offboarding process, or explain to an auditor why you excluded a control from your Statement of Applicability. Templates can also make you feel further along than you are. A dashboard at 90% can hide an ISMS that won’t survive Stage 1, because the missing 10% is the management system itself. Insider Note: The Stage 1 problem we see most on software-only projects is a risk assessment copied straight from the platform’s default risk library. The risks are generic, the scores are almost identical, and nothing ties back to the company’s own assets. Auditors notice within minutes, and it weakens the Statement of Applicability that’s built on it. The other problem is ownership. Software assumes someone inside the company will drive the project. At most startups that’s a CTO or ops lead who already has a full-time job, and the subscription renews whether the work gets done or not. Limits of a Consultant-Only Approach A consultant working without automation spends billable days on things a platform does for free, like chasing screenshots, updating evidence trackers, and collecting the same proof again before every surveillance audit. You pay more and wait longer. You also end up with a program that’s only accurate on the day it’s handed over. Once the engagement ends, the evidence goes stale and year-two surveillance turns into a scramble. ISO 27001 Consultant vs Software: Side-by-Side Comparison Factor Consultant only Software only Hybrid (consultant + platform) Time to audit readiness 3 to 6+ months Highly variable; depends on internal expertise As little as 6 weeks for well-scoped

Uzbekistan regulates artificial intelligence through two documents. The first is Law ZRU-1115, signed on 21 January 2026. It amends existing legislation to define AI, stops anyone from basing decisions about people’s rights on AI output alone, and fines companies that process personal data unlawfully with AI. The second is the set of Ethical Rules approved by Order No. 3787, in force since 17 June 2026, which spell out what developers, implementers, and users actually have to do. Uzbekistan hasn’t passed a standalone AI act, and its rules don’t sort systems into risk tiers or require conformity assessments. The framework is short and blunt, and it’s already enforceable. Below we walk through what each document requires, who it applies to, how it stacks up against the EU AI Act, and what a company using AI in Uzbekistan should do next. Uzbekistan AI Regulation at a Glance (TL;DR) Instrument Date What it does Who it binds Law ZRU-1115 Signed 21 January 2026 Defines AI in law, sets general rules for AI-built information resources and systems, bans legally significant decisions based only on AI, adds fines for unlawful AI processing of personal data State bodies, organizations, website owners, anyone processing personal data with AI Order No. 3787 (Ethical Rules) Registered 14 March 2026, in force 17 June 2026 Sets eight mandatory ethical principles and lists rights and obligations for developers, implementers, and users Individuals and companies developing, implementing, or using AI in Uzbekistan Law No. 1125 (Personal Data amendments) Adopted 26 March 2026 Limits data localization to biometric, genetic, and local telecom user data, and allows cross-border transfers under conditions Personal data operators, including AI providers AI Strategy until 2030 (RP-358) 14 October 2024 Sets national targets for AI adoption, infrastructure, and skills Government bodies What Is Law ZRU-1115? The law’s official title is a mouthful: “On making additions and changes to certain legislative acts of the Republic of Uzbekistan in connection with the regulation of relations arising from the use of artificial intelligence.” Put simply, it’s an amending law. Instead of creating a new AI code, it writes AI into laws that were already on the books. When It Was Signed and When It Took Effect The Legislative Chamber of the Oliy Majlis adopted the bill on 12 August 2025, and the Senate approved it on 1 November 2025. President Shavkat Mirziyoyev signed it on 21 January 2026. You can read the official text in Lex.uz, Uzbekistan’s national legislation database. The law set out the principles and the penalties. The day-to-day detail arrived later with the Ethical Rules, which came into force on 17 June 2026. For compliance planning, treat mid-June 2026 as the point when the whole framework started applying. Why Uzbekistan Amended Existing Laws Instead of Passing a Standalone AI Act Uzbekistan wants more AI, not less. Its national strategy sets numeric targets for adoption, investment, and local computing capacity, and a heavy EU-style act would have worked against them. So lawmakers kept it light. They defined AI, drew two hard lines (human control over decisions that affect people’s rights, and protection of personal data), and left the Ministry of Digital Technologies to fill in the rest through secondary rules. Businesses get less legal certainty, and the government gets to move faster. Which Laws ZRU-1115 Changes For businesses, two amendments matter most. The Law “On Informatization” (ZRU-560-II, 2003) now contains a legal definition of AI, a new article on using AI in information resources and systems, duties for website owners, and updated powers for the ministry in charge. The Code on Administrative Liability now includes an offense for processing and spreading personal data unlawfully using AI. The Legal Definition of Artificial Intelligence in Uzbekistan Under the amended Law “On Informatization,” AI is a set of technological solutions that imitate human cognitive functions, including learning on their own and solving problems, and that produce results on specific tasks comparable to what a person could do. That’s deliberately broad. It covers generative AI, machine learning classifiers, recommendation engines, and most agentic systems. The Ethical Rules add a narrower term, the AI system: software built on AI that can find, collect, store, analyze, process, evaluate, and use data, and make decisions on its own based on that data. If your product makes a decision from data, or shapes one, assume it counts. Key Rules Introduced by Law ZRU-1115 General Principles for Using AI in Information Systems and Resources The new article in the Law “On Informatization” starts from harm. Information resources created with AI, and information systems running on AI, must not harm people’s life, health, freedom, honor, or dignity, or violate their other inalienable rights. The standard is short and open-ended. It gives regulators something to enforce against without saying in advance what counts as harm. Principle-based rules like this deserve to be taken seriously precisely because the edges are undefined. Human Oversight: No Decisions on Rights and Freedoms Based Solely on AI Most coverage leads with this provision, and it’s easy to see why. When someone makes a legally significant decision that affects human rights and freedoms, they can’t rely only on conclusions produced by AI systems or AI-built information resources. AI can feed into the decision, but a person has to make it. That applies to loan denials, benefit eligibility, hiring rejections, licensing outcomes, and disciplinary action. In each case, someone needs to look at the AI output and own the final call. Insider Note: In AI governance engagements, teams rarely struggle to show that a review step exists. What they struggle to show is that the reviewer could disagree, and sometimes did. If a human clicks “approve” on every AI recommendation and nobody ever records an override, auditors will see automation with a signature on top. Build the override path and log when people use it, starting on day one. Powers of the Authorized State Body (Ministry of Digital Technologies) ZRU-1115 makes the Ministry of Digital Technologies the authorized state body for AI. Among its new jobs, it’s

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 works when most of the plumbing already exists and your job is to formalize it, fill the gaps, and prove it all works. It falls apart when you’re building the foundations and documenting them at the same time. Go through this table honestly before you promise a customer a date. Six weeks is realistic if… Plan for 10 to 16 weeks if… Your product runs on a major cloud provider You host on-premise or across several data centers You already use an identity provider with SSO Every tool has its own login and password You have fewer than about 50 employees You have multiple offices, subsidiaries, or products in scope One named person owns the project with 10 to 15 hours a week Compliance is “everyone’s job,” so in practice nobody owns it An engineer can give you 15 to 20 hours in weeks 3 and 4 Engineering is fully committed to a launch You only need the Security criteria You need Availability, Confidentiality, or Privacy on day one Landing mostly in the right-hand column doesn’t mean you should throw the plan out. Give each week two weeks instead of one and follow the same order. What “SOC 2 Ready” Means at the End of Week 6 SOC 2 doesn’t give you a certificate. An independent CPA firm examines your controls against the AICPA Trust Services Criteria and writes a report, and which of the two report types you go for decides what you can show a buyer after week 6. A Type I report checks whether your controls are designed properly on a single date. Once you’re ready, a Type I audit can start almost right away. A Type II report checks whether those controls kept working over an observation period of at least three months, and usually six to twelve. Most enterprise procurement teams want Type II in the end. Being “ready” at the end of this plan means your in-scope controls are in place, you can pull evidence for any of them on request, and your auditor is booked. From there you either start a Type I audit or open your Type II observation window. Plenty of buyers will sign with a Type I report plus a letter from your auditor saying the Type II period is underway. Important: The Type II clock doesn’t start until your controls are running. If readiness slips by a week, your Type II report slips by a week too. Founders who tell a prospect “we’ll have SOC 2 in Q3” often forget this and end up renegotiating the deal. Before Week 1: Four Decisions to Make First Settle these before the clock starts. If you change any of them halfway through, you’ll redo work. Scope. Decide which systems, teams, and data the report covers. For most SaaS companies that’s the production environment, the code repository, the identity provider, customer data stores, and any support tools that touch customer data. Corporate systems that never see customer data can usually stay out. Trust Services Criteria. Security (also called the Common Criteria) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Report type. Pick Type I if a deal is blocked right now and the buyer will accept it. If there’s no deadline, go straight to Type II. You’ll need it eventually, and skipping Type I saves you an audit fee. Owner and tooling. Name one person who’s accountable for the plan, and decide where your controls and evidence will live. The tooling choice gets its own section below. Pro Tip: Adding Criteria Only add optional criteria when a customer contract or security questionnaire asks for them. Each one brings more controls to set up and more evidence to collect, and you can widen the scope in next year’s audit. Spreadsheet or Compliance Software: Choosing Your Tracking Tool Every SOC 2 program needs a system of record, meaning one place where each control, its owner, its status, and its evidence live. You can run it yourself in a spreadsheet or a GRC platform, or have a consultant implement it for you. The right choice depends mostly on which report you’re after and how much of your team’s time you can spare. A spreadsheet is free and familiar. It also makes you understand your own environment before you automate any of it. For a Type I, or for a small team with a tight scope, a well-built spreadsheet can take you all the way to the audit. Axipro’s free GRC workbook for SOC 2 and ISO 27001 covers all 33 SOC 2 Common Criteria plus the optional criteria, with evidence, risk, policy, and gap trackers built in. It has no macros and opens straight in Google Sheets or Excel. A GRC platform connects to your cloud, identity provider, code repository, and HR system.