CAP 1850 cybersecurity: what gap analysis finds that auditors cannot verify
Amara OkaforApril 29, 2026
Key takeaways
CAP 1850 Section 5 change management compliance is assessed against documentation. Auditors verify that change management procedures exist and are described. They do not verify that code review gates are technically enforced in the deployment pipeline — a bypass-able approval step in GitLab or GitHub satisfies the documentation requirement while permitting unauthorized deployments.
The most consistently exploitable CAP 1850 gap in MRO and aviation component manufacturing environments is default or weak credentials on OT-connected systems: SCADA interfaces, avionics test rigs, and ground support equipment management systems that are in scope for Section 4 access control but outside the identity management tools used to produce compliance evidence.
CAP 1850 Section 7 supplier assurance requirements are routinely satisfied by tier-1 questionnaires that do not extend to tier-2 and tier-3 vendors. Navigation database providers, avionics firmware suppliers, and airport system integrators regularly have access paths into airline or airport operator environments through update mechanisms that bypass the assessed perimeter.
Network segmentation between IT and OT environments is one of the hardest CAP 1850 controls to verify through documentation review and one of the most reliably incomplete in technical assessment — the documented architecture and the enforced architecture diverge in predictable ways that external enumeration reveals.
CAP 1850 security monitoring evidence requests from regulators require machine-readable log exports aligned to specific incident timelines, not summary reports. Organizations that produce PDF incident summaries for internal governance cannot produce what a regulator actually requests without a separate evidence reconstruction exercise.
TL;DR
CAP 1850 compliance assessments verify documentation. The controls that documentation review cannot verify — whether change management gates are technically enforced, whether OT-connected systems have default credentials, whether network segmentation holds between IT and OT, whether tier-2 suppliers have access paths into the production environment — are where the real gaps sit. Aviation organizations that pass CAP 1850 audits without technical verification of these controls have documentation that describes security, not security that matches the documentation.
The deployment that the change management policy did not stop
An aviation component manufacturer had a CAP 1850 compliant change management policy. Section 5 requirements were documented: all production changes required a code review approval before deployment, test environment validation before promotion, and a named approver on record. The GitLab pipeline had approval gates configured. The documentation was clean and the last audit found no findings in change management.
The approval gate was configured as a single approver requirement with no restriction on self-approval. A developer could create a merge request, approve it themselves, and deploy to production without any independent review. The gate existed in the pipeline. It satisfied the documented requirement for an approval step. It enforced nothing about the independence or quality of that approval. Three unauthorized configuration changes had made it to production in the previous six months. The audit had not asked to see deployment logs — it had asked for the change management policy and a sample of completed change records. Both were present and correct.
How CAP 1850 change management gaps survive documentation review
CAP 1850 Section 5 requires that changes to critical aviation systems go through a controlled process including assessment, approval, testing, and documentation. Auditors verify this by reviewing the change management policy, examining sample change records, and confirming that the required fields — approver, test sign-off, deployment date — are populated. This is a documentation review. It confirms the process exists and that records are being created.
What it cannot confirm is whether the process is enforced technically or merely performed administratively. The difference matters enormously in practice. An administratively enforced process depends on people following it consistently. A technically enforced process makes deviation impossible or at least detectable. A pipeline that requires an approval click but permits self-approval is administratively compliant and technically permissive. A pipeline that requires approval from a named list of reviewers who cannot include the submitter is technically enforced.
The same distinction applies to testing requirements. A change record with a test sign-off field populated satisfies the documentation requirement. Whether the tests described actually ran against an environment that resembles production is a different question. Aviation component manufacturers with limited lab infrastructure commonly test against simplified environments and mark the test field complete. The record is accurate — testing occurred. Whether the testing would have caught the vulnerability that reached production is the question the record cannot answer.
Technical verification of change management enforcement requires access to the pipeline configuration, the merge request history, and the deployment logs. This is what an attacker would examine when looking for gaps in the software update process. It is not what a standard CAP 1850 audit examines.
Example
An MRO organization's CAP 1850 assessment covered change management for their maintenance management system, which has direct interfaces to aircraft maintenance record systems used by multiple airline clients. The change management documentation was complete and had been audited twice without findings. A pipeline review found that the protected branch configuration in their Git repository had been modified 4 months earlier, removing a requirement for two-reviewer approval on main branch merges. The change was made during a staffing shortage and was intended as temporary. It had not been reverted. All deployments since that change had gone through with single-reviewer approval. The last two audits reviewed the change management policy, which still specified two-reviewer approval. Neither audit reviewed the pipeline configuration.
Verifying CAP 1850 change management enforcement technically requires: reviewing the CI/CD pipeline configuration for approval gate settings including self-approval restrictions; checking protected branch rules in the version control system against the documented approval requirements; pulling deployment logs for the assessment period and confirming each production deployment has a corresponding change record with an approval from a non-submitting reviewer; and reviewing any pipeline configuration changes during the assessment period that may have modified enforcement settings. This takes hours, not days. Documentation review takes minutes. The effort difference is why technical verification is rarely part of a standard compliance audit.
What CAP 1850 gap analysis finds in aviation environments
Assessment base: Vulnox gap analysis and technical assessments in aviation, MRO, and airport operator environments, 2023-2025
OT-connected systems with default or weak credentials outside identity management scope
In aviation environments with OT or OT-adjacent infrastructure — MRO workshops with network-connected test equipment, airports with building management systems on the same network as operational systems, cargo handling environments with warehouse management systems interfacing to flight operations — the credential configuration on non-IT-managed devices is consistently the finding that surprises clients most. SCADA web interfaces, avionics test rig management consoles, ground support equipment diagnostic ports, and environmental control systems with IP connectivity frequently retain default credentials because they are not enrolled in the identity management platform used to produce access control compliance evidence. The CAP 1850 Section 4 access control assessment reviews the identity management platform. It does not enumerate every IP-connected device on the network.
A device with default credentials that has network connectivity to any in-scope system provides a lateral movement path that exists independently of every other access control the organization has implemented. The path does not require exploitation of a vulnerability — it requires knowing the default credential for the device model, which is publicly documented by the manufacturer. In MRO environments, these devices are often on the same network segment as maintenance management systems with airline client data. The CAP 1850 access control finding and the data exposure risk are the same problem.
IT/OT network segmentation that is documented but not technically enforced
Network architecture diagrams submitted for CAP 1850 compliance review show segmentation between IT networks and OT or operational networks. The segmentation is implemented via firewall rules and VLAN configuration. In technical assessments that enumerate reachable hosts from IT network positions, the segmentation holds for standard TCP traffic on expected ports. It does not hold for the operational protocols used by OT systems — Modbus, DNP3, proprietary avionics communication protocols — because firewall rules were written around IP and port without application-layer inspection of the OT traffic those rules are supposed to control. A host on the IT network can reach OT system management interfaces on the ports those systems listen on because the firewall rule permits the management IP range rather than specific source hosts.
The architecture diagram describes the intended segmentation. The firewall ruleset implements a subset of it. The gap between intended and implemented segmentation is only visible through active enumeration from representative network positions — a step that documentation review cannot replicate. For CAP 1850 compliance, the segmentation is assessed against the architecture documentation. For security, it is assessed against what a host in each network zone can actually reach.
Tier-2 and tier-3 supplier access paths into assessed environments
CAP 1850 Section 7 supplier assurance programs assess tier-1 suppliers: direct vendors with contractual relationships and supplier questionnaires on file. The update and maintenance mechanisms through which tier-1 suppliers deliver software and data pull from their own upstream suppliers. A navigation database provider that is a tier-1 supplier receives database updates from a tier-2 data aggregator. An avionics software vendor uses a third-party code signing service. An airport system integrator uses a remote access platform from a vendor that the airport operator has never assessed. The access path from tier-2 or tier-3 supplier into the aviation operator's environment exists through the tier-1 supplier's update mechanism. The supplier assurance program has assessed the tier-1 relationship. It has not assessed the path.
Supply chain attacks against aviation targets do not require compromising a direct vendor relationship. They require finding the least-assessed point in the chain that has a delivery mechanism into the target environment. Tier-2 and tier-3 suppliers are that point by definition — they are outside the scope of supplier assurance programs that stop at tier-1. Mapping the full update and access path for each tier-1 supplier, not just the tier-1 relationship itself, is the only way to assess the actual attack surface.
The finding that aviation compliance teams do not expect
Common belief
Aviation organizations approaching CAP 1850 gap analysis typically expect their gaps to be in areas they have not formally addressed: supplier questionnaire coverage, documentation of specific Section references, or formal risk assessment methodology. They expect the gap analysis to find missing documentation and produce a remediation list of policies to write.
What we found
In aviation environment assessments where we ran technical enumeration before reviewing documentation, every engagement found networked devices reachable from the IT environment that were not represented in the access control evidence submitted for compliance review. The count varied from 3 devices to 23. In every case, at least one device had credentials that had not been changed from vendor defaults. None of these devices appeared in the compliance documentation because the compliance assessment process did not include device-level enumeration of the OT-adjacent network.
The findings that matter are not in the documentation layer. Aviation organizations subject to CAP 1850 have typically invested in documentation — the regulatory environment and audit pressure produce that outcome reliably. The gaps are in the enforcement layer: change management gates that are configured but bypassable, network segmentation that is documented but partially implemented, access controls that cover the identity management platform but not every network-connected device.
The counterintuitive result is that more mature documentation programs correlate with more confident self-assessment, which correlates with less rigorous internal verification of whether the documented controls actually operate as described. An organization that has been through multiple audit cycles without findings trusts its documentation. The documentation is accurate as a description of the intended state. Whether the implemented state matches the intended state is a different question, and mature compliance programs are not reliably better at asking it.
In aviation specifically, the OT environment compounds this. IT security teams understand IT controls. OT systems — avionics test equipment, ground support systems, building management infrastructure — are often managed by operations teams who are not part of the compliance program. The IT compliance documentation is complete. The OT environment it shares a network with is not assessed in the same way.
What CAP 1850 gap analysis misses when it starts from documentation
CI/CD pipeline configuration versus change management policy
CAP 1850 change management compliance is assessed against policy documents and change records. Pipeline configuration — the technical mechanism that enforces or fails to enforce the policy — is not a standard audit artifact. Changes to pipeline configuration, such as removing two-reviewer requirements or adding bypass conditions, do not automatically produce change records in the change management system because they are infrastructure changes rather than application changes. The policy continues to specify the control that the infrastructure change has disabled. The compliance record shows no gap. The deployment history shows bypasses.
Update mechanism security for software and data that enters the environment
CAP 1850 Section 7 supplier assurance focuses on the supplier relationship and the supplier's security posture. It does not systematically address the integrity of the update mechanism through which supplier software and data enter the organization's environment. A supplier with a good security posture whose update server is compromised delivers malicious updates through a trusted channel. The supplier assurance assessment of the supplier's security posture does not detect a compromise of their update infrastructure. Verifying the integrity of the update mechanism — code signing validation, update server certificate pinning, hash verification of delivered artifacts — is a separate control that falls between supplier assurance and change management in most CAP 1850 compliance programs.
Legacy system interfaces in safety-critical data paths
Aviation environments contain systems that predate modern security design: legacy communication protocols between ground systems and aircraft, older maintenance management systems with flat-file data interfaces, and avionics test equipment with serial or early-generation network interfaces. These systems appear in risk assessments with compensating controls noted — network isolation, physical access restrictions, protocol limitations. The compensating controls are documented. Whether they actually isolate the legacy system from paths that could be exploited requires technical verification of reachability, not documentation review. Legacy systems in aviation are often the most stable components of the environment and the least frequently assessed.
Third-party remote access paths used for maintenance and support
MRO organizations and airport operators use vendor remote access for system maintenance, avionics software updates, and operational support. These access paths are typically point-in-time — established for a specific maintenance event and then terminated. In practice, termination is inconsistent. Vendor VPN accounts, jump host credentials, and remote desktop sessions established for maintenance events sometimes remain active after the maintenance window closes. The access path is assessed as part of the supplier assurance program during onboarding. Whether it is actually terminated after each use is an operational control that documentation review does not verify.
What aviation organizations say before a CAP 1850 gap analysis — and what it reveals
'Our change management is solid — every change goes through the GitLab approval process and we have the records to prove it.'
Root cause:The change records exist and are complete. The question is whether the approval process is technically enforced or administratively performed. If the pipeline permits self-approval, if protected branch rules can be modified by the same developers who submit changes, or if the approval requirement applies to the main branch but not to deployment branches, the record-keeping is accurate and the enforcement is absent. Change records prove that the process was followed in the sense that the fields were completed. They do not prove that the process could not have been bypassed.
'We've assessed all our key suppliers and have questionnaires on file for each one.'
Root cause:Key suppliers are the direct vendor relationships the procurement team knows about. The tier-2 and tier-3 suppliers that tier-1 vendors use for their own operations, software components, and data sourcing are not key suppliers in the same sense — they are not in the procurement relationship. But they have access paths into the environment through the tier-1 supplier's update and delivery mechanisms. The questionnaire program is complete for the relationships it was designed to cover. It was not designed to cover the full supply chain path.
'Our IT and OT networks are segmented — we have a firewall between them and the architecture is documented.'
Root cause:The firewall exists and the architecture is accurate. The question is whether the firewall rules implement the segmentation the architecture describes, and whether they implement it for the protocols and ports that OT systems actually use. Firewall rules written around IP ranges without application-layer awareness of OT protocols permit OT-protocol traffic from IT network positions if that traffic is on the same IP and port range as permitted management traffic. The segmentation is real for the protocols the firewall rules were written around. It may not be real for the protocols OT systems communicate on.
Where CAP 1850 enforcement is heading
CAA will update CAP 1850 assessment methodology within 3 years to require technical verification of change management pipeline enforcement as a separate evidence category from change record review, following a documented incident where a compromised update path bypassed a CAP 1850 compliant change management process.
The aviation sector's increasing dependency on software-defined systems — from flight management to airport operations — makes software update integrity a predictable enforcement focus. The gap between documented change management and technically enforced change management is well understood in the security community and will be well understood by regulators following the first high-visibility incident where the vector was an update path that bypassed compliant documentation. The methodology update is the predictable regulatory response.
Confidence: mediumCAP 1850 methodology revisions published by the CAA between 2025 and 2028. If updated methodology does not introduce technical pipeline verification requirements, this prediction is wrong on the mechanism though the underlying gap remains real.A UK aviation operator will experience a security incident traced to a tier-2 or tier-3 supplier access path that was not in scope for the operator's CAP 1850 supplier assurance program, and the post-incident review will establish that questionnaire-based tier-1 assurance does not satisfy the spirit of Section 7 for complex supply chains.
The structural conditions are established: tier-1 supplier assurance programs are the norm, tier-2 and tier-3 suppliers have access paths through update mechanisms, and no current CAP 1850 guidance explicitly requires assurance to extend beyond direct supplier relationships. A supply chain incident that traverses these conditions will produce a regulatory response clarifying the scope of Section 7 obligations. The aviation sector's supply chain attack surface is large enough that this outcome is probable within a 3-year window.
Confidence: highNo publicly documented CAP 1850 enforcement action or incident report citing tier-2 or tier-3 supplier access path failure by May 2028. This would suggest the structural gap exists but has not yet been exploited through documented aviation targets.
What CAP 1850 audits verify and what they do not
CAP 1850 audits are documentation reviews with technical vocabulary. The evidence requested — change records, access control policies, supplier questionnaires, architecture diagrams — describes controls as they are understood to operate. The controls are assessed against those descriptions. Whether the description matches operational reality is not consistently tested, because testing it requires a different methodology than reviewing documentation.
This is not a criticism specific to CAP 1850 or to aviation regulators. It is a property of audit methodologies built around evidence collection rather than technical verification. The methodology produces consistent results across audited organizations and is scalable to the CAA's oversight responsibilities. What it cannot produce is assurance that the controls described in the evidence actually operate as described.
Cyber Essentials Plus — for all its limitations — gets this right in one respect: it requires external technical verification rather than accepting self-described controls at face value. CAP 1850 would produce materially better security outcomes if its assessment methodology included mandatory technical verification of change management enforcement, network segmentation, and access control coverage for OT-connected devices. The documentation review is necessary but insufficient as a standalone assurance mechanism for safety-critical systems.
Counterargument
The counterargument is that mandatory technical verification at the depth required to actually test these controls would make CAP 1850 assessments prohibitively expensive and operationally disruptive for smaller aviation organizations — regional airports, smaller MROs, specialized component manufacturers — who cannot absorb the cost of rigorous technical testing on the same cycle as documentation review. This is a real constraint. The response is risk-tiering: mandatory technical verification for organizations with direct interfaces to flight-critical systems, with documentation-based assessment remaining appropriate for lower-risk aviation supply chain participants.
Running a CAP 1850 gap analysis that finds technical gaps
Step 1 — pipeline configuration review versus change record review. Organizations prepare for CAP 1850 change management assessment by ensuring change records are complete and correctly formatted. The pipeline configuration that either enforces or fails to enforce the policy described in those records is not a standard audit artifact and is not routinely reviewed. It is where the gap between documented process and enforced process lives, and finding it requires a different starting point than change record sampling.
- 1Security engineer or external assessor
Review the CI/CD pipeline configuration for every production deployment path, not just the change management policy document. Check protected branch settings for self-approval permissions. Check whether pipeline configuration files themselves are protected by the same approval requirements as application code. Pull the deployment log for the most recent 90 days and cross-reference each production deployment against the change record system to confirm that approval records exist and that the approver is not the same person as the submitter.
Expected outcomeA verified change management enforcement status that distinguishes between controls that are configured and controls that are technically enforced, with a list of any deployments in the review period that do not have a corresponding change record with independent approval.
- 2Security engineer or network team
From a host on the IT network, enumerate reachable hosts on OT network segments using the protocols those systems actually communicate on — not just ICMP and common TCP ports, but the management interfaces and protocols specific to the OT equipment in the environment. Compare the reachable host list against the network architecture diagram. Any host reachable from an IT network position that the architecture shows as isolated is a segmentation gap. Any management interface reachable from the IT network that should require physical or OT-network-only access is a finding.
Expected outcomeA verified segmentation status that reflects what IT-network hosts can actually reach, rather than what the firewall rules were designed to permit, with specific findings for reachable management interfaces and OT systems.
- 3IT or OT team with security lead
Enumerate every network-connected device in the environment that is not enrolled in the identity management platform: IP cameras, environmental controls, OT-connected test equipment, ground support system interfaces, building management components. For each device, check the credential configuration against the vendor default. This is the check that the CAP 1850 access control audit does not run and that the technical assessment will.
Expected outcomeA complete inventory of network-connected devices outside identity management scope, with credential status per device and a prioritized list of devices with default or weak credentials for immediate remediation.
- 4Supplier relationship manager or security lead
For each tier-1 supplier that delivers software, firmware, or data updates into the environment, map the full update path: where does the update originate, what systems does it traverse before reaching your environment, and what verification is applied to confirm the update's integrity before it is accepted. Identify any tier-2 or tier-3 dependencies in that path — third-party code signing services, upstream data providers, remote access platforms — and determine whether those dependencies have been assessed in any capacity.
Expected outcomeA supply chain path map for each tier-1 update relationship, with identified tier-2 and tier-3 dependencies that are outside current supplier assurance scope and a prioritized list for initial assessment based on access depth and criticality of the delivered artifact.
One thing to do this week
Open the protected branch configuration in your production code repository and check two things: whether the branch requires approval before merge, and whether the approval configuration excludes the author of the change from being their own approver.
If self-approval is permitted, every change management record you have produced that was self-approved is a record of a process that was performed without the independent review it was documented as requiring. That is not a documentation gap — it is a control gap that your compliance records describe as closed.
Fixing it is a single configuration change. Finding it requires looking at the pipeline rather than the policy. That distinction is the difference between a gap analysis that confirms your documentation and one that finds what your documentation does not cover.
Further Reading
Gap Analysis
CAP 1850 gap analysisDigital Footprint
digital footprint analysisEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
CAP 1850 aviation cybersecurity compliance and what gap analysis findsNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionNational Vulnerability Database NIST
NIST National Vulnerability DatabaseThird-Party Risk Management
third-party risk management
Frequently Asked Questions
What does CAP 1850 cybersecurity require for change management, and what do audits miss?
CAP 1850 Section 5 requires controlled change management for critical aviation systems including approval, testing, and documentation. Auditors verify this through policy review and change record sampling. What audits do not verify is whether the approval process is technically enforced in the CI/CD pipeline — whether self-approval is blocked, whether protected branch rules match the documented requirements, and whether pipeline configuration changes are themselves subject to change control. A pipeline that permits self-approval satisfies the documentation requirement while enforcing nothing about independent review.
What are the most common CAP 1850 gap analysis findings in MRO and aviation manufacturing environments?
The most consistent findings are: default credentials on OT-connected devices outside identity management scope (avionics test equipment, SCADA interfaces, ground support system management consoles); network segmentation that is documented in architecture diagrams but partially implemented in firewall rules that do not account for OT-specific protocols; change management pipeline configurations that permit self-approval despite policies requiring independent review; and tier-2 and tier-3 supplier access paths through update mechanisms that are outside the scope of tier-1 supplier assurance programs.
How does CAP 1850 Section 7 supplier assurance apply to tier-2 and tier-3 suppliers?
CAP 1850 Section 7 requires assessment of security risks associated with suppliers. In practice, supplier assurance programs cover tier-1 direct vendor relationships. Tier-2 and tier-3 suppliers — the vendors that tier-1 suppliers use for software components, data sources, and operational support — have access paths into the aviation operator's environment through tier-1 update and delivery mechanisms. These paths are not addressed by tier-1 questionnaire programs. Mapping the full update path for each tier-1 supplier, identifying all upstream dependencies with delivery access, is the only way to assess the actual supply chain attack surface.
What technical evidence does CAP 1850 security monitoring require?
CAP 1850 Section 6 security monitoring requirements are assessed against monitoring policy and capability documentation. When regulators investigate incidents, what they request is structured log data — event logs with specific timestamps and system identifiers exportable for independent analysis — not summary reports or PDF incident documents. Organizations that produce governance-ready summary reports for internal compliance review cannot produce regulator-ready structured log exports without a separate evidence reconstruction exercise. Building the export capability before it is requested is the gap between compliance documentation and regulatory evidence readiness.
How should IT/OT network segmentation be verified for CAP 1850 compliance?
CAP 1850 network segmentation compliance is assessed against architecture documentation and firewall policy review. Technical verification requires active enumeration from IT network positions to determine what OT-network hosts and management interfaces are actually reachable — using the protocols OT systems communicate on, not just standard IT ports. Firewall rules written around IP ranges without OT-protocol awareness may permit OT system management interface access from IT network positions on ports that the rules were not intended to restrict. The architecture describes intended segmentation. Technical enumeration finds what is actually enforced.
What is the difference between CAP 1850 compliance and genuine aviation cybersecurity posture?
CAP 1850 compliance is assessed through documentation review: policies, change records, supplier questionnaires, architecture diagrams, and evidence that required processes exist. Genuine security posture is assessed through technical verification of whether those processes are enforced and whether the controls described operate as documented. The gap between the two is consistent: change management gates that are bypassable, OT devices with default credentials outside compliance scope, segmentation that is documented but incompletely implemented, and update paths that carry undocumented supply chain risk. Compliance documentation and operational security are not the same thing, and CAP 1850's assessment methodology does not reliably close the gap between them.
How often should a CAP 1850 gap analysis include technical verification rather than just documentation review?
Technical verification should occur at minimum before each formal compliance assessment cycle and after any significant infrastructure change: CI/CD pipeline modifications, network architecture changes, new supplier onboarding, or OT equipment additions. Documentation review alone will not detect pipeline configuration drift, new OT-connected devices with default credentials, or segmentation gaps introduced by firewall rule changes. Annual technical verification aligned with the compliance cycle, with targeted verification after significant changes, is the minimum frequency for maintaining an accurate picture of control enforcement versus control documentation.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.