What is Arizona’s P8000 Information Security Policy, Complete Guide

Over the past two decades, Arizona has experienced sustained population growth, a strengthening economy and a steady influx of new residents and businesses. As people became increasingly reliant on digital services for everything from licensing and benefits to education and public safety, the demand for technology that is secure, dependable and available at all times grew rapidly, and with it the need for a consistent and well governed technology foundation also increased.

How Does Arizona Manage Statewide IT and Information Security?

To support this need the State established dedicated departments with clear mandates for technology and security governance. Enterprise IT management was assigned to the Arizona Strategic Enterprise Technology Office (ASET) within the Department of Administration (ADOA), which oversees statewide planning, standards and system reliability. Statewide security and privacy responsibilities were placed with the Arizona Department of Homeland Security (AZDOHS) through the Statewide Information Security and Privacy Office (SISPO) and Arizona Cyber Command, which lead policy development, risk management and operational defense.

To carry out these responsibilities AZDOHS, through the State CISO, created a comprehensive set of statewide security policies, standards and procedures (PSPs) that define how agencies must safeguard systems and data.

The P1000 PSP series establishes the statewide framework that governs how all policies and standards are created, reviewed and approved. Within this structure AZDOHS is authorized to develop and publish the P8000 Information Security Policies.

What is Arizona’s P8000 Information Security Policy Series?

The P8000 Information Security Policy Series provides a uniform set of security, privacy and supply-chain risk policies and procedures that address the expanding threat landscape, protect sensitive state data and manage the risks introduced by modern digital services. Within this series, the P8120 Information Security Policy defines the statewide information security program that every agency must implement.

Our guide provides a clear and practical explanation of how agencies can implement the P8120 requirements within the P8000 Information Security Policy series. It also clarifies how documentation, system categorization, control selection, assessments and ongoing monitoring fit together so that agencies can meet statewide expectations with accuracy and confidence.

Who Must Comply with P8000 Information Security Policies?

Arizona’s enterprise IT and security-governance statutes apply primarily to Budget Units (BUs).

A “budget unit” encompasses any state department, commission, board or agency that receives or expends state funds. This definition includes the Arizona Board of Regents (ABOR) but excludes:

• The universities operated under ABOR
• Community-college districts
• The legislative and judicial branches

While ABOR itself is included, the universities operate under independent security governance through ABOR Policy 9-202 (Information Security), which requires each university to implement institution-wide security programs, access-control mechanisms and data-classification standards consistent with state and federal requirements.

For all other executive-branch BUs, adhering to enterprise-IT standards and complying with statewide security and privacy requirements is mandatory.

How to Request Exceptions or Tailor Controls in P8120

P8120 allows BUs to request exceptions when necessary. PSPs may be expanded or tailored through the Statewide Policy Exception Procedure. This process allows BUs to adjust the control baseline, either BU-wide or for specific systems, when justified and approved under the statewide exception process, consistent with NIST 800-53 PL-11.

Before submitting an exception request, BU subject matter experts should first check with the vendor and the state or agency procurement office to determine whether the existing contract already provides additional products or services that would allow the system to meet PSP requirements. (P8102 4.2.1)

How is P8000 Regulated and Enforced?

Compliance is enforced jointly by the Director of the AZDOHS and the Statewide CISO through a combination of oversight, required submissions and corrective-action authority. These mechanisms include mandatory annual reporting, such as system inventories, SSPs, SAPs and POA&Ms, along with formal document reviews to verify completeness and adequacy.

The Statewide CISO may require corrective actions, including the implementation of additional controls, independent assessments or migration of systems to approved hosting environments.

Under A.R.S. § 41-4282(D), the Director may also suspend Budget Unit (BU) systems that present unmitigated and unacceptable risk.

How P8120 Serves as the Core Information Security Policy in the P8000 Series

The P8000 series includes several policies, each focused on a specific security domain, such as access control, incident response, media protection or personnel security. P8120 defines the statewide Information Security Program itself and serves as the foundation for everything else in the P8000 series.

P8120 Information Security Program Policy translates Arizona’s statutory cybersecurity mandate into a governance model, a NIST-aligned control structure and a set of mandatory requirements that apply to every system supporting state operations.

It sets the expectations for how agencies identify and categorize systems, implement and monitor controls, manage risk, respond to incidents and document security posture through standardized statewide artifacts.

How Budget Units Carry Out P8120 Requirements

P8120 assigns specific responsibilities to key roles within each Budget Unit to ensure that information systems are properly managed, documented, and secured. These roles work together to carry out statewide requirements, maintain accurate system information and ensure compliance with Arizona’s Information Security Program.

P8120 Control Requirements

Arizona’s P8120 Information Security Policy defines the minimum security controls every Budget Unit (BU) must implement, covering system planning, risk management, vulnerability management, program governance, control assessments and continuous monitoring to protect state information systems.

1. System Security Planning Requirements

Build a Complete Security Foundation for Every System.
BUs must create and maintain accurate, current System Security Plans (SSPs) for every information system. They must start by thinking about how the system works, what data it handles, the risks it faces and the controls in place to protect it.

For building an SSP, the BU must:

• Describe what the system does and how it supports the BU’s work.
• Define the system’s boundary which includes information about what’s inside it, what connects to it and what is allowed.
• List all information types the system processes, stores or transmits.
• Identify everyone who has a role in managing or supporting the system.
• Explain how the system is categorized and why it received that impact level.
• Document any known threats or risks that concern the BU.
• Include results from a privacy risk assessment if the system handles personal data.
• Describe the system’s operating environment and any external dependencies.
• Outline the security and privacy requirements the system must meet.
• Identify the control baseline or overlay selected for the system.
• Explain which controls are already in place and which are planned, including reasons for tailoring.
• Record risk decisions made during system design or architecture discussions.
• Note any activities that require coordination with the CIO, ISO or other system owners.
• Review and update the SSP every year.
• Ensure the BU CIO reviews and approves the SSP before it is implemented.

2. Security Policy Requirements

Maintain a Full Set of Security Policies for the BU.
BUs must operate with clear, written security, privacy and supply chain risk policies and procedures that guide how systems, data and people are managed. These policies form the foundation of secure operations and ensure everyone understands their responsibilities.

For maintaining required security policies, the BU must:

• Create policies for areas such as access control, incident response, media protection, physical security, account management, system auditing, system maintenance, contingency planning and privacy.
• Make sure these policies follow state laws, federal rules and statewide standards.
• Assign an official to write, maintain and distribute these policies to the right people.
• Keep all policies up to date and review them every year.
• Retain all policy documents for at least six years from the date of its creation or the date it last was in effect, whichever is later.
• Ensure all staff who rely on these policies can easily access them.
• Update policies whenever technology, threats or agency operations change.

3. Risk Management Requirements

Identify, Categorize and Manage Risks Across All Systems.
P8120 requires BUs to understand the risks facing each system and document how serious the impact would be if something went wrong. This helps agencies prioritize where to focus their security resources.

For managing risk, the BU must:

• Perform an impact assessment to determine how harmful a security failure would be.
• Categorize each system as Standard or Protected and explain why.
• Conduct annual risk assessments to identify threats, vulnerabilities and potential harm.
• Update risk assessments when major system or environmental changes occur.
• Assess privacy risks for systems handling personal information.
• Share risk assessment results with the CIO, ISO and system owners.

Beyond system-level risk, agencies must also conduct:

• Supply chain risk assessments and update them annually (e.g., vendor dependencies, third-party components).
• Maintain a vendor risk assessments process for any external entity with system access or responsibility (contractors, cloud service providers and third-party systems).
• Cloud and third-party risk assessments for systems processing confidential or regulated data.

4. Vulnerability Management Requirements

Find and Fix Security Weaknesses Quickly.
BUs must continuously look for weaknesses in their systems and take timely action to fix them. P8120 builds a structured, repeatable approach for identifying vulnerabilities and reducing exposure.

For managing vulnerabilities, the BU must:

• Use trusted sources to stay updated on new vulnerabilities.
• Assign a risk level (high, medium, low) to each vulnerability found.
• Run vulnerability scans every quarter and whenever new threats appear.
• Use scanning tools that follow recognized standards.
• Review and analyze scan reports.
• Fix legitimate vulnerabilities within 30 days.
• Scan again after remediation to verify the issue is resolved.
• Share lessons learned with other system teams to prevent repeat issues.
• Maintain a way for the public to report vulnerabilities.
• For protected systems, use independent qualified vendors for external scans and ensure scanning tools are updated before each assessment.

5. Information Security Program Management Requirements

Run a Well-Structured Security Program.
P8120 requires BUs to treat security as an ongoing program. The Information Security Program Management ensures the BU has the people, processes and structure needed to protect systems over time.

For governing the security program, the BU must:

• Appoint a senior information security officer with authority and resources.
• Allocate budget and resources to support security activities.
• Develop and maintain a Plan of Action and Milestones (POA&M) process that document all remedial actions for security, privacy and supply chain risks across the BU’s systems.
• Review POAMs regularly.
• Maintain an accurate, yearly-updated inventory of all BU-managed systems.
• Track performance measures to understand how well security efforts are working.
• Develop and maintain an enterprise architecture that takes security, privacy, and related risks into account.
• Update critical infrastructure protection plans when applicable.
• Develop and annually update the BU’s risk management strategy.
• Build a supply chain risk management strategy and keep it current and protected.
• Implement controls to prevent counterfeit components and manage supplier risks.
• Dispose of system components securely to prevent data leakage.
• Respond to identified risks in line with the BU’s risk tolerance.
• Conduct privacy impact assessments before launching new PII-related systems.
• Identify critical system components through a criticality analysis when the system is being designed, modified or upgraded.
• Use a formal process to approve system security, assign the right people to handle it and make sure this process fits into the BU’s larger risk management approach.
• Define mission processes with appropriate security and privacy protections.
• Operate an insider threat program.
• Establish a security and privacy workforce development and improvement program to train and grow its security and privacy staff.
• Maintain plans for conducting testing, training and monitoring activities.
• Stay connected with external security communities and share threat information.

6. Control Assessment and Authorization Requirements

Test Controls Regularly and Approve Systems Before Use.
P8120 requires BUs to verify that security controls actually work. This includes regular assessments, independent testing for protected systems, and formal system authorization before systems go live.

For assessments and authorization, the BU must:

• Develop a control assessment plan describing which controls will be tested and how.
• Test controls every quarter to confirm they are working as intended.
• Produce written reports documenting results.
• Share results with CIOs, CISOs and privacy officers.
• Use impartial, independent assessors for protected systems.
• Perform security assessments on any third-party handling confidential data.
• Test quarterly for unauthorized wireless access points.
• Approve and document all system connections by using formal agreements, record the security and privacy requirements for each connection, and review and update these agreements every year.
• Apply “deny-all, permit-by-exception” rules for external connections on protected systems.
• Require contracts that ensure third parties safeguard confidential data.
• Maintain POAMs that list planned fixes for security weaknesses and update them each year.
• Assign an authorizing official who must approve systems before use and reauthorize them every three years.
• Implement continuous monitoring with defined metrics, ongoing assessments and quarterly reporting to the State CISO.
• Use independent assessors to support continuous monitoring for protected systems.
• Conduct annual penetration tests for protected systems and retest after any major changes.

7. Operational Procedures Requirements

Document How Security Is Performed Day to Day.
BUs must ensure their operational practices are well-documented so that monitoring, testing, and remediation activities are performed consistently.

For maintaining operational procedures, the BU must:

• Document all procedures for security monitoring and testing.
• Make sure staff know, understand, and follow these procedures.
• Record all remediation actions taken.

P8120 Information Security Policy: Step-by-Step Implementation Guide

Step 1: Build and Maintain a System Inventory

To have a complete understanding of what the Budget Unit (BU) owns and operates, it must:

• Maintain a full inventory of all information systems, including hardware, software, data, users and business processes.
• Document ownership, categorization and security responsibilities for each system.
• Update and submit the inventory every year by July 1.

Step 2: Categorize Each System

Perform an Impact Assessment for every system

• Evaluate the sensitivity of each system data and mission criticality.
• Determine how damaging a loss of confidentiality, integrity or availability would be.
• Based on this evaluation, assign an impact level: Limited Adverse Impact or Serious Adverse Impact.

Assign the System Category

• Use the results of the impact assessment to assign the system to one of two categories: Standard or Protected.
• Document the categorization and rationale in the SSP.
• Have the BU ISO review it and the BU CIO formally approve it.

Step 3: Identify Controls

Determine the Controls That Apply

• After understanding the full scope of the system environment, BUs must identify all required statewide controls based on the system’s category.
• Apply the Standard baseline for systems with limited impact.
• Apply the enhanced Protected baseline for higher-risk systems.
• Tailor controls where needed to reflect the system’s mission, sensitivity and architecture.

Step 4: Assess Security and Privacy Risk

Conduct a Control-Based Risk Assessment

Conduct a comprehensive risk assessment for each system to identify security and privacy risks and ensure those risks are understood, documented and managed over time. This assessment must:

• Identify threats and vulnerabilities affecting the system.
• Assess the likelihood and impact of unauthorized access, use, disclosure, disruption, or modification.
• Evaluate risks to individuals when PII is involved.
• Update the assessment annually or when major changes occur.
• Share results with the CIO, ISO, and system owner.

In addition, establish and maintain a supply chain risk assessment for BU systems, components and services by:

• Conducting a supply chain risk assessment to identify vendor and supplier related risks.
• Updating the supply chain risk assessment annually or whenever changes to suppliers, system environments or other conditions introduce new supply chain risks.

Conduct Privacy Impact Assessments (PIAs)

Perform a PIA for every system, program or activity that processes personally identifiable information (PII). A PIA must be completed:

• Before developing or procuring any technology that will process PII.
• Before initiating any new collection of PII involving ten or more individuals.
• For any technology that enables physical or virtual (online) identification or contact of a specific individual.

Use PIAs to identify, evaluate and mitigate privacy risks early in the system or program lifecycle, ensuring privacy considerations are addressed before the system is built, acquired or modified.

Implement Vendor Risk Management

Establish and maintain a formal vendor risk management program as required by P8120 §§6.3.5, 6.3.6 and 6.5.3. This program must operate as part of a broader, comprehensive security strategy and apply to all external service providers, including cloud service providers, contractors, supply-chain partners and any third parties involved in BU systems.

The vendor risk management program must:

• Identify and evaluate vendor-related threats to the information system, system components and information services.
• Assess risks associated with the vendor’s access, involvement, operation or influence over BU systems and data.
• Ensure appropriate protections are in place to mitigate risks arising from third-party relationships.

Conduct Cloud Product and Third-Party Risk Assessments

Perform a third-party risk assessment for any external entity, such as a cloud provider, contractor or service partner, authorized to process, store or transmit confidential data on behalf of the BU. This assessment must:

• Evaluate the likelihood and magnitude of harm resulting from unauthorized access, use, disclosure, modification or destruction involving the third party.
• Be documented and maintained in accordance with HIPAA, PCI DSS and other applicable requirements for handling confidential or regulated data.
• Confirm that the System Owner has notified ADOHS of the correct data-impact level before acquiring any system, service or cloud product that involves a third-party provider.

Develop a Supply Chain Risk Management Strategy

Every BU must develop and maintain a supply chain risk management (SCRM) strategy that governs how supply chain risks will be identified, mitigated and monitored throughout the system lifecycle, from research and design to acquisition, delivery, operations, maintenance and eventual disposal.

This strategy must be reviewed and updated annually or in response to new threats, organizational changes or environmental shifts. It must also be protected from unauthorized access or modification.

To operationalize the strategy, the BU should carry out the following activities:

• Establish a dedicated SCRM team to lead and support SCRM activities.
• Implement controls and processes to identify weaknesses in key supply chain elements, protect systems and components against supply chain risks and document all selected and implemented controls within the SCRM plan.
• Assess and review supplier-related risks tied to systems, components or services delivered by external parties.
• Establish agreements and procedures with supply chain partners for notifying the BU of supply chain compromises, audit results or assessment findings.
• Perform random inspections of systems and components frequently enough to detect potential tampering.
• Develop and enforce anti-counterfeit policies and procedures, including detection and reporting of counterfeit components to the source and to the State CISO.*
• Dispose of system components using approved sanitization techniques to ensure sensitive data is removed.

*This includes training personnel to identify counterfeit components and maintaining configuration control of components awaiting repair or reinstallation.

Establish a Vulnerability Management and Scanning Process

Implement a comprehensive vulnerability management process to identify, assess and remediate weaknesses in agency systems. This process must:

• Use reputable external sources to stay informed of newly discovered security vulnerabilities.
• Assign a risk ranking (e.g., high, medium, low) to each newly identified vulnerability.

• Monitor and scan agency information systems and hosted applications at least quarterly.
• Conduct additional scans whenever new vulnerabilities are identified through internal or external channels.

Your vulnerability scanning tools and techniques must support:

• Enumerating platforms, software flaws and misconfigurations.
• Using standardized formats for checklists and test procedures.
• Measuring the potential impact of detected vulnerabilities.

After scanning:

• Analyze vulnerability scan results and monitoring reports.
• Remediate legitimate vulnerabilities within 30 days, based on risk.
• Share relevant vulnerability information with BU-defined personnel to help identify systemic weaknesses across other systems.
• Provide a public reporting channel to receive external vulnerability notifications.

For Protected systems, the BU must also:

• Maintain a formal process for identifying and assigning risk rankings to newly discovered vulnerabilities.
• Address vulnerabilities and conduct rescans to verify that all high-risk vulnerabilities have been fully resolved in accordance with their assigned risk level.

Step 5: Document The Security Posture

Develop and Maintain the System Security Plan (SSP)

A System Security Plan (SSP) documents how a system operates, how it is secured and how its risks are managed, including its boundaries, mission context, information types, categorization, threats, controls and dependencies. To create and maintain an accurate SSP, the BU must:

• Compile all system information needed to describe boundaries, functions, data, roles, risks and controls.
• Validate system categorization and impact levels and ensure they are reflected consistently throughout the plan.
• Map controls to the system by identifying which NIST-aligned controls apply and how they are implemented.
• Record any gaps or deficiencies discovered during assessments, scans or monitoring activities.
• Update the SSP continuously as changes occur to architecture, integrations, hosting, data sensitivity or system ownership.
• Submit the SSP for CIO approval and maintain it as the authoritative description of the system’s security posture.

Document and Track Remediation Through the POA&M

Every deficiency identified during system assessments or SSP development must be recorded in the Plan of Actions and Milestones (POA&M). The BU must:

• Document each remediation action including required tasks, responsible personnel and expected completion dates.
• Ensure POA&Ms align with statewide reporting expectations and include risks that affect operations, assets, individuals or the State.
• Review POA&Ms regularly to ensure remediation activities remain aligned with the BU’s risk-management strategy.
• Update POA&Ms as work is completed so statewide oversight reflects current risk posture.

Submit Required Documentation for Statewide Review

To maintain statewide visibility into system posture, each BU must submit required documentation for approval by July 1 each year. This includes:

• A complete system inventory with classification assignments and system owners for all information systems.
• A System Security Plan and a System Security Assessment Plan for each Protected information system.
• A Plan of Actions and Milestones for each Protected information system.

Step 6: Maintain Continuous Monitoring

P8120 requires each BU to maintain ongoing oversight of its systems through continuous monitoring activities and structured testing and training processes. These steps ensure that security and privacy controls remain effective, aligned with risk and responsive to changing conditions.

Implement Continuous Monitoring

• Develop a system-level continuous monitoring strategy.
• Define system metrics and monitoring frequencies.
• Conduct ongoing security control assessments.
• Monitor security status using those metrics.
• Correlate and analyze assessment results.
• Take action when risks or deficiencies are identified.
• Report system security status to the State CISO quarterly.
• Use independent assessors for Protected systems.

Conduct Security and Privacy Control Assessments

• Develop a formal security and privacy control assessment plan that defines:
  • The scope of the assessment
  • The controls being evaluated
  • The assessment procedures
  • The assessment environment
  • The assessment team and their roles
• Assess system controls quarterly to determine whether they are implemented correctly, operating as intended and achieving the required security outcomes.
• Produce a control assessment report documenting all assessment results.
• Provide assessment results to the BU CIO, BU CSO, BU Privacy Officer, State Privacy Officer and the State CSO.

Maintain Testing and Training Processes

• Implement a process to ensure that plans for system security testing, training and monitoring are developed, maintained and executed in a timely manner.
• Review all testing, training and monitoring plans to ensure they align with the BU’s risk management strategy and organization-wide risk response priorities.

Common Pitfalls When Implementing P8120

Despite having clear statewide requirements, many agencies struggle with the practical side of implementing P8120. Most issues don’t come from the controls themselves, but from gaps in documentation, inconsistent execution, and missing processes that weaken an otherwise solid security program. Below are the most common pitfalls BUs encounter during implementation and why they matter.

• Incomplete or Outdated System Inventories. Many BUs start risk management with an inventory that is missing systems, components or integrations. When this happens, everything else that depends on it, including categorization, risk assessments, SSPs, and monitoring, ends up out of sync. This makes it difficult for the State to understand the agency’s actual risk
• Incorrect or Unsupported System Categorization. Some systems are labeled “Standard” by default, without a documented impact assessment to support that decision. Under-categorizing systems means applying fewer controls than required, putting the BU at risk and creating friction during statewide review.

• SSPs Treated as One-Time Documents. When the SSP is stale, it no longer reflects how the system is built, what data it handles, or what risks exist, making it ineffective for governance or oversight.

• Missing or Weak POA&Ms. Without accurate POA&Ms, there is no clear record of what issues exist, whether they are being addressed, or how risks evolve over time.

• Vendor and third-party risks are often overlooked. Agencies may assume the vendor is “handling security,” which leaves critical risks unexamined and unmanaged.

• Vulnerability Scans Not Completed or Not Remediated. Some agencies run quarterly scans but do not analyze results or remediate findings within the required 30-day window. Others fix issues but forget to perform rescans to verify remediation.

• Continuous Monitoring Implemented Only Partially. Agencies may collect logs or conduct occasional assessments but fall short of maintaining the full monitoring workflow P8120 requires—one that includes metrics, ongoing assessments, correlation of security data, response actions, and quarterly reporting.

• Interconnections Not Properly Authorized or Documented. Systems sometimes connect to printers, servers, APIs, or cloud services without formal documentation or annual review. These undocumented or outdated connections often become attack points, especially if no one is tracking their purpose or need.

• Policies Do Not Match Actual Practices. A BU may maintain strong policies on paper, but if teams do not follow them, the gap becomes a compliance finding and operational risk.

How GRC Platforms Support P8000 Compliance

A modern GRC platform helps agencies operationalize Arizona’s Information Security requirements by automating assessments, centralizing documentation, standardizing control implementation and ensuring that agency leadership, system owners and statewide authorities see the same compliance picture.

Here’s how a GRC platform can help Arizona agencies:

Risk & Impact Assessment Automation

GRC platforms streamline P8120’s annual assessment expectations by enabling agencies to build reusable impact-assessment templates, distribute them to system owners and automatically consolidate results. This ensures system categorization, supply-chain assessments and privacy evaluations remain consistent across all Budget Unit (BU) systems.

Centralized Security & Compliance Dashboards

Dashboards give BU CIOs, ISOs and program leadership a real-time view of system risk, assessment status, POA&M progress and P8000 compliance. Agencies can track vulnerabilities, outstanding actions, incident-response training and continuous-monitoring metrics, all in one place.

Integrated Control Mapping for P8000

Modern GRC platforms map Arizona’s P8120 control expectations directly to NIST SP 800-53, StateRAMP, FedRAMP and internal agency standards. This reduces duplication, ensures consistent control inheritance and helps agencies demonstrate compliance with statewide policies using a single integrated control set.

Workflow-Driven POA&M and Risk Response Management

Structured workflows guide staff through P8120 and P8240 requirements by assigning ownership, setting deadlines, triggering review cycles and documenting mitigation progress. Every POA&M action becomes tracked, auditable and reportable to the State CISO and Cyber Command.

Continuous Monitoring & Control Testing

GRC platforms support continuous monitoring by automating assessment cycles, sending reminders for annual reviews, scheduling vulnerability scans and tracking control effectiveness over time. This enables agencies to detect changes in risk exposure early and maintain readiness for statewide oversight.

Incident Response Documentation & Reporting

For P8240 requirements, GRC software centralizes incident-response plans, training logs, exercises, reporting workflows and post-incident documentation. Automated routing ensures security and privacy incidents reach the correct statewide authorities within required timelines.

Isora GRC for Arizona’s P8000 Information Security Policies

Arizona’s PSPs require agencies to maintain an organized, repeatable and well-documented security program. Agencies must coordinate assessments, maintain an accurate system inventory, document risks and exceptions and produce oversight-ready reporting for statewide compliance reviews.

In practice, this means collecting data from many departments, tracking risks and owners across systems and keeping policies, exceptions and inventories synchronized. Most agencies rely on spreadsheets and email, which makes it difficult to maintain consistency, prove compliance or demonstrate continuous monitoring to ADOA-ASET. A centralized platform like Isora GRC eliminates these barriers.

Assessment Management

P8000 and P1000 require agencies to assess controls, document security responsibilities and maintain evidence of compliance across systems, business units and third parties.

Isora GRC provides structured assessment management built for lean state teams. Agencies can run recurring internal assessments, validate control responsibilities and collect evidence through collaborative questionnaires. Findings published directly into the risk register and remediation plans so documentation remains consistent across the program.

With this, agencies eliminate manual aggregation, standardize their P8000/P1000 compliance reviews and maintain real-time visibility into security posture across departments and systems.

Inventory Management

P8000 requires agencies to maintain an accurate inventory of systems, vendors, applications and data classifications. These records must map to responsibilities defined under P1000.

Isora GRC maintains a connected inventory where each system, application or vendor is tied to associated assessments, owners, data classifications, risk items and exceptions. Metadata fields capture business impact, unit ownership and policy mappings to P8000/P1000 requirements.

Agencies gain a unified system of record that supports statewide reporting expectations, improves accuracy during audits and strengthens continuous monitoring by linking risks directly to the systems that introduce them.

Risk Management and Response

P8000 requires formal identification, tracking and mitigation of risks, including responsibilities for risk acceptance, escalation and documentation.

Isora GRC’s live risk register allows agencies to capture risks directly from assessments, assign responsible units, document mitigation or acceptance decisions and track progress over time. Exception management supports the recording of compensating controls or accepted risks with expiration dates and review workflows.

Agencies maintain real-time visibility into enterprise and system-level risks, enabling leadership to prioritize remediation, document risk acceptance per policy and demonstrate compliance maturity to oversight bodies.

Reports & Scorecards

P8000 and P1000 require agencies to report on risk posture, assessment findings and compliance readiness.

Isora GRC generates audit-ready dashboards and scorecards that consolidate assessment results, inventory data and risk register records into structured, exportable reports. These outputs are suitable for ADOA-ASET oversight, internal audits and legislative or executive-level briefings.

Leadership receives clear, real-time insights into program health and compliance status, enabling transparent communication and faster response to statewide directives.

Arizona P8000 Information Security Policy FAQs

Who must comply with the Arizona P8000 Information Security Policies?

All executive-branch Budget Units (BUs) are required to comply with the Arizona P8000 Information Security Policy series. A Budget Unit includes any state department, board, commission or agency that receives or expends state funds. The Arizona Board of Regents (ABOR) is included, but universities operating under ABOR follow their own governance under ABOR Policy 9-202, not P8000. Legislative and judicial branches are excluded. For covered agencies, adherence to statewide security, privacy, and supply-chain requirements is mandatory.

Isora gives BUs a structured way to maintain the assessments, inventories, risks, and documentation required by statewide oversight, replacing scattered spreadsheets with a connected system of record.

How do Budget Units implement P8120 under the Arizona P8000 Information Security Policy framework?

Budget Units implement P8120 by building a complete system inventory, categorizing systems, selecting the appropriate statewide control baseline, assessing risks, documenting controls in the SSP and POA&M, and performing continuous monitoring. P8120 defines specific responsibilities for the BU Director, CIO, ISO, and system owners to ensure that documentation, control execution, testing, and statewide reporting are performed correctly. Every system must be governed according to the statewide Information Security Program described in the P8000 series.

Isora operationalizes these requirements by connecting system records, assessments, risks, and remediation tasks in one workspace. Teams can define ownership, capture evidence, and keep documentation aligned with P8120 expectations through structured workflows.

What annual documentation must agencies submit for P8000 Information Security Policy compliance?

Every Budget Unit must submit required P8000 documentation by July 1 each year. This includes:
• A complete system inventory with categorization and system owners
• A System Security Plan (SSP) and System Security Assessment Plan (SAP) for every Protected system
• A Plan of Action and Milestones (POA&M) for each Protected system
These artifacts allow statewide oversight teams to verify completeness, risk posture, and progress on remediation under the Arizona P8000 Information Security Policy.

What is required in a System Security Plan (SSP) for Arizona P8000 Information Security Policy compliance?

Under P8120 Information Security Policy, every SSP must describe the system boundary, mission purpose, data types, roles, categorization rationale, threats, risks, controls, architecture, external dependencies, privacy impacts, and planned improvements. The SSP must reflect the current state of the system, map required controls to their implementation details, and document any tailoring or exceptions. It must be reviewed annually, updated as changes occur, and approved by the BU CIO before use.

Why do agencies struggle with SSP accuracy under the P8120 Information Security Program?

Many agencies struggle with SSP accuracy because system inventories are incomplete, categorization decisions lack documented impact analyses, and system changes aren’t reflected in the SSP over time. When the SSP is treated as a one-time document instead of a living description of the system’s security posture, it becomes outdated and misaligned with real-world architecture, integrations, data flows, or risks. This creates gaps during statewide P8000 reviews and makes compliance harder to maintain.

Isora links assessments, risks, controls, and remediation activities directly to the system record, allowing SSP information to stay synchronized with actual system state and eliminating the “stale SSP” problem.

What vendor and supply-chain risk assessments are required under P8120?

P8120 requires BUs to maintain a vendor risk management program and a supply-chain risk assessment for all systems, components, and third-party services. This includes annual supply-chain reviews, third-party security assessments for any external entity handling confidential data, cloud-product assessments, and evaluation of vendor access, architecture, and data-handling practices. Agencies must document supplier risks, anti-counterfeit controls, reporting procedures, and any required notifications to the State CISO.

This content is for informational purposes only and does not constitute legal or compliance advice. See our full disclaimer.