Unpatched systems are the single most common finding in Aramco CCC audits. When assessors evaluate a vendor's infrastructure against the SACS-002 standard, patch management under TPC-11 is one of the first areas they examine -- and one of the easiest places to fail. The control is straightforward in principle: keep your systems up to date. In practice, meeting the specific SLAs, documenting the evidence, and covering every layer of the software stack requires a disciplined, automated approach that most small and mid-size vendors simply do not have in place.

This guide breaks down exactly what TPC-11 requires, the patching timelines you must meet, how to prioritize vulnerabilities using CVSS scores, and the audit evidence you need to produce. We also cover how MassiveGRID's managed patch management service automates the entire process so your infrastructure stays compliant without consuming your IT team's bandwidth.

What TPC-11 Requires: The Core Obligation

TPC-11 within the SACS-002 framework mandates that all systems used in connection with Aramco operations must have current security patches applied. This is not a suggestion or a best-effort guideline -- it is a binary compliance requirement. Either your systems are patched within the defined SLAs, or you fail the control.

TPC-11 (Patch Management): The vendor shall implement and maintain a patch management program that ensures all operating systems, firmware, applications, and middleware are updated with the latest security patches within defined timeframes. The program must include automated patch scanning, documented deployment procedures, rollback capabilities, and compliance reporting.

The scope of TPC-11 is deliberately broad. It does not limit itself to operating system updates. The control covers every software component that could introduce a vulnerability into systems handling Aramco data or connecting to Aramco networks. This includes:

Patching Frequency and SLA Expectations

SACS-002 does not prescribe a single patching deadline for all updates. Instead, it establishes a risk-based approach where patching urgency is determined by the severity of the vulnerability being addressed. The expected timelines align with industry standards and CVSS (Common Vulnerability Scoring System) severity ratings.

Severity Level CVSS Score Range Patching SLA Examples
Critical 9.0 -- 10.0 14 calendar days Remote code execution, authentication bypass, zero-days with active exploitation
High 7.0 -- 8.9 30 calendar days Privilege escalation, significant information disclosure, denial of service
Medium 4.0 -- 6.9 60 calendar days Cross-site scripting, limited information disclosure, local exploits
Low 0.1 -- 3.9 90 calendar days Minor information leaks, theoretical exploits requiring unlikely conditions

The 14-day window for critical patches is the most important number for CCC compliance. When a critical vulnerability is disclosed -- for example, a remote code execution flaw in OpenSSL, a kernel exploit in Linux, or a zero-day in a web server -- the clock starts from the date the vendor releases the patch, not from the date you become aware of it. This means you need automated vulnerability scanning to detect new patches as soon as they are released, not manual checking on a weekly or monthly schedule.

Auditor reality check: CCC assessors will pull a list of all CVEs published in the 90 days prior to the audit, cross-reference them against the software versions running in your environment, and verify that critical and high-severity patches were applied within the required windows. If a single critical patch missed the 14-day SLA and you cannot produce a documented exception with compensating controls, the control fails.

What "Calendar Days" Means in Practice

The SLA is measured in calendar days, not business days. Weekends and holidays count. If a critical patch is released on a Thursday evening and you have a policy of patching only on Tuesdays, you have already consumed four days of your 14-day window before the first eligible maintenance window arrives. This is why scheduled deployment windows must be frequent enough to accommodate the shortest SLA.

CVSS-Based Prioritization for Vulnerability Patching

The Common Vulnerability Scoring System (CVSS) provides the objective framework that SACS-002 relies on for patch prioritization. Understanding how CVSS scores are calculated helps you make defensible decisions about patching order when multiple vulnerabilities are disclosed simultaneously.

CVSS v3.1 Base Score Components

The base score considers eight metrics that describe the characteristics of the vulnerability:

Metric What It Measures Impact on Score
Attack Vector (AV) How the vulnerability is exploited (Network, Adjacent, Local, Physical) Network-accessible vulnerabilities score highest
Attack Complexity (AC) Conditions beyond the attacker's control needed for exploitation Low complexity scores higher
Privileges Required (PR) Level of access the attacker needs before exploiting No privileges required scores highest
User Interaction (UI) Whether a user must take action for exploitation to succeed No interaction required scores higher
Scope (S) Whether the vulnerability impacts resources beyond its security scope Changed scope scores higher
Confidentiality (C) Impact on confidentiality of information High impact scores higher
Integrity (I) Impact on integrity of information High impact scores higher
Availability (A) Impact on availability of the system High impact scores higher

Beyond the Base Score: Temporal and Environmental Factors

While the base CVSS score determines your patching SLA tier, practical prioritization should also consider temporal and environmental factors:

Scope: What Must Be Patched

One of the most common mistakes vendors make is treating patch management as synonymous with "Windows Update" or yum update. TPC-11 requires patching across the entire software stack, and auditors will check each layer independently.

Operating System Patches

This is the layer most organizations handle reasonably well, but common gaps include:

Firmware Updates

Firmware is the most overlooked patching category and a frequent audit finding. The scope includes:

Application and Middleware Patches

Every application running on your servers falls under TPC-11 scope:

Third-Party Software Patching

Third-party software is the blind spot in most vendors' patch management programs. While operating system patches are relatively straightforward (most OS vendors provide centralized update mechanisms), third-party applications often lack automated update capabilities and require manual intervention.

Common Third-Party Patching Gaps

Software Category Common Examples Why It Gets Missed Risk Level
Java runtimes Oracle JDK, OpenJDK, AdoptOpenJDK Multiple Java versions installed; application compatibility concerns Critical -- Java vulnerabilities are heavily exploited
PDF readers Adobe Acrobat Reader, Foxit Reader Installed on workstations, not managed centrally High -- common malware delivery vector
Browser plugins Flash (legacy), Java plugin, Silverlight Legacy applications depend on outdated plugins Critical -- should be removed entirely if possible
Remote access tools TeamViewer, AnyDesk, RealVNC Installed ad-hoc by employees; no central inventory Critical -- direct remote access if compromised
Compression utilities 7-Zip, WinRAR Considered low-priority; rarely included in patch cycles Medium -- archive parsing vulnerabilities exist
SSL/TLS libraries OpenSSL, GnuTLS, LibreSSL Bundled with applications; requires application rebuild Critical -- encryption and authentication failures

The challenge with third-party software is inventory. You cannot patch what you do not know exists. TPC-11 compliance requires a complete software inventory that includes every application, library, and runtime installed on every system in scope. This inventory must be continuously updated, not just created once during initial setup.

Patch Testing and Rollback Procedures

TPC-11 does not require you to blindly apply every patch the moment it is released. It requires a managed process that balances speed with stability. This means testing patches before production deployment and having rollback procedures ready in case a patch causes issues.

A Compliant Patch Testing Workflow

  1. Vulnerability scan detects new patch: Automated scanning identifies that a new security patch is available for a component in your environment. The CVSS score determines the urgency tier and applicable SLA.
  2. Risk assessment: The patch is evaluated for potential impact on production services. Does it require a reboot? Does it affect a shared library used by multiple applications? Does the vendor's release notes mention any known issues?
  3. Staging environment deployment: The patch is deployed to a staging or test environment that mirrors production. Automated tests verify that critical services still function correctly after patching.
  4. Approval and scheduling: Based on test results, the patch is approved for production deployment and scheduled within the next available maintenance window that falls within the SLA.
  5. Production deployment: The patch is applied to production systems during the scheduled window. System health checks are performed immediately after deployment.
  6. Verification: A post-deployment vulnerability scan confirms that the patch was successfully applied and the vulnerability is remediated.
  7. Documentation: The entire process -- from detection to verification -- is logged with timestamps, approval records, and scan results for audit evidence.

Rollback Capability

Every patch deployment must have a documented rollback plan. This means:

Key distinction: A rollback is not the same as an exception. Rolling back a patch means a vulnerability is reintroduced into the environment. If a rollback is necessary, it must be paired with compensating controls (firewall rules, WAF rules, network segmentation) until a compatible patch or fix is available, and the entire situation must be documented as a formal exception with a remediation deadline.

Audit Evidence: What Assessors Need to See

Passing TPC-11 is not just about having patched systems -- it is about proving your systems are patched with documented evidence. CCC assessors will request specific artifacts during the audit, and you need to produce them quickly and completely.

Required Audit Artifacts

Artifact What It Shows Format Expected
Patch compliance report Percentage of systems with all applicable patches applied, broken down by severity Dashboard screenshot or PDF export from patch management tool showing 95%+ compliance
Vulnerability scan results Current vulnerability posture across all in-scope systems Scan report from Nessus, Qualys, Rapid7, or equivalent showing no critical/high unpatched CVEs past SLA
Patch deployment logs Historical record of when specific patches were deployed to specific systems Timestamped logs from patch management platform or configuration management tool
Exception register Any patches that could not be applied within SLA, with documented justification and compensating controls Formal exception document with approval signatures, compensating controls listed, remediation deadline
Patch management policy Written policy defining patching SLAs, responsibilities, testing procedures, and rollback plans Signed policy document with version history, reviewed within the last 12 months
Software inventory Complete list of all software installed across in-scope systems Automated inventory report, not a manually maintained spreadsheet
Rollback evidence Proof that rollback procedures exist and have been tested Test records showing successful rollback execution, snapshot retention policy

The 95% Compliance Threshold

While SACS-002 does not explicitly state a percentage threshold, CCC assessors in practice expect to see at least 95% patch compliance across the environment. This means at least 95% of all applicable patches must be applied within their respective SLA windows. The remaining 5% must be covered by documented exceptions with compensating controls and remediation timelines.

Falling below 90% compliance is almost always a control failure. Between 90% and 95%, the outcome depends on the quality of your exception documentation and the severity of the unpatched vulnerabilities. Above 95% with clean exception management, you are in strong standing.

Why Unpatched Systems Are the #1 Audit Failure

Across CCC assessments, patch management consistently emerges as the most frequently failed control. There are several reasons for this pattern:

1. The Evidence Is Binary and Objective

Unlike some controls where compliance is a matter of interpretation (e.g., "adequate" logging or "appropriate" access controls), patch status is objective. A vulnerability scanner produces a factual report: this CVE exists on this system, and the patch has or has not been applied. There is no room for argument or creative interpretation. The assessor runs a scan, and the results speak for themselves.

2. The Scope Is Vast

Every piece of software on every system is in scope. A vendor might have excellent OS patching but completely overlook Java runtime updates, or keep servers patched but forget about the firmware on their network switches. TPC-11 requires comprehensive coverage, and any gap becomes a finding.

3. Small Teams Lack Automation

Many Aramco vendors are small to mid-size companies with limited IT staff. Without automated patch management tools, keeping dozens or hundreds of systems patched across multiple software layers is simply not feasible through manual effort. The IT team patches what they can, deprioritizes what seems less urgent, and accumulates technical debt that becomes visible during the audit.

4. Legacy Systems and Compatibility Fears

Vendors often delay patches out of fear that an update will break a critical application. This is a legitimate concern, but TPC-11 does not accept "we were afraid it might break something" as a valid exception. The control requires you to have a testing process that validates patches before production deployment, eliminating the fear factor through process rather than avoidance.

5. Patching Is Continuous, Not One-Time

Unlike controls that can be implemented once and maintained with minimal effort (e.g., configuring a firewall rule), patching requires ongoing, perpetual effort. New vulnerabilities are disclosed every day. The moment you achieve 100% compliance, the clock starts ticking on the next round of patches. Organizations that treat patch management as a project rather than a continuous process inevitably fall behind.

Patch Management Checklist for CCC Compliance

Use this checklist to evaluate your current patch management program against TPC-11 requirements. Every item must be satisfied for compliance.

Policy and Governance

Inventory and Scanning

Testing and Deployment

Rollback and Recovery

Reporting and Evidence

Integration with Other SACS-002 Controls

Patch management does not exist in isolation within SACS-002. TPC-11 intersects with several other controls, and weaknesses in patching often cascade into failures across related control areas.

Related Control How It Connects to Patch Management Risk of Non-Compliance
TPC-3 (Endpoint Protection) Antivirus and EDR solutions must themselves be kept up to date. Outdated signature definitions or agent versions are a patching failure. Unpatched endpoint protection cannot detect latest threats, creating a double vulnerability
TPC-4 (Firewall) Firewall firmware and rule sets must be patched. Compensating firewall rules may be needed when application patches are deferred. Unpatched firewall vulnerabilities can bypass all other security controls
TPC-5 (Network Monitoring) Monitoring systems should detect and alert on exploitation attempts targeting known unpatched vulnerabilities. Without monitoring, you may not detect active exploitation during the patching window
TPC-6 (Logging) Patch deployment activities must be logged. Failed patch installations must generate alerts. Without logging, you cannot prove when patches were applied or detect deployment failures
TPC-7 (Backup) Pre-patch backups are required for rollback capability. Backup systems themselves must be patched. Without backups, rollback is impossible, making patch deployment an unacceptable risk
TPC-2 (Access Control) Patch management systems require privileged access. Access to these systems must be controlled with MFA and least-privilege principles. Compromised patch management access could be used to deploy malicious updates

The interconnected nature of these controls means that a mature patch management program strengthens your overall SACS-002 compliance posture, while a weak one creates cascading audit findings across multiple control areas.

How MassiveGRID's Patch Management Service Works

For vendors seeking Aramco CCC certification, building an enterprise-grade patch management program from scratch is a significant undertaking. MassiveGRID's managed Patch Management service provides a turnkey solution that covers every TPC-11 requirement out of the box.

Automated Vulnerability Scanning

MassiveGRID deploys continuous vulnerability scanning across all managed systems. Scans cover the full stack -- operating systems, installed applications, middleware, runtimes, and libraries. New CVEs are detected within hours of public disclosure, and each is automatically classified by CVSS severity to determine the applicable patching SLA.

The scanning engine maintains a complete software inventory that is updated with every scan cycle, ensuring there are no blind spots where unpatched software could hide.

Scheduled Deployment Windows

Patches are deployed through pre-agreed maintenance windows that are scheduled to meet TPC-11 SLAs. For environments with critical-severity SLAs, maintenance windows occur at minimum twice per week. Each deployment follows the full testing workflow:

  1. Patch identified and classified by CVSS severity
  2. Pre-deployment snapshot taken automatically
  3. Patch tested in staging environment (for high-impact changes)
  4. Patch deployed to production during scheduled window
  5. Post-deployment health check validates system stability
  6. Verification scan confirms vulnerability is remediated

Emergency patches for actively exploited zero-day vulnerabilities can be deployed outside regular maintenance windows through an expedited approval process.

Compliance Dashboards

The MassiveGRID compliance dashboard provides real-time visibility into your patch compliance status. Key metrics displayed include:

The dashboard is designed to produce audit-ready evidence. Reports can be exported as PDF documents suitable for direct submission to CCC assessors, with no reformatting or additional preparation required.

Exception Tracking

When a patch cannot be applied -- because of application compatibility, vendor dependency, or a required change freeze -- MassiveGRID's exception management workflow ensures the situation is properly documented:

Rollback Capability

Every patch deployment performed by MassiveGRID includes automatic pre-deployment snapshots. If a patch causes system instability, the rollback process is:

  1. Automated health checks detect the issue (service failure, performance degradation, application error)
  2. MassiveGRID operations team is alerted and initiates rollback within the defined rollback SLA
  3. System is restored from the pre-deployment snapshot
  4. The patch is logged as a failed deployment with a compatibility issue
  5. Compensating controls are applied for the underlying vulnerability
  6. The vendor is contacted for a compatible fix, and the exception is tracked until resolution

Snapshots are retained for a minimum of 7 days post-deployment, providing ample time to identify delayed-onset issues.

Third-Party and Firmware Coverage

Unlike basic OS patching tools, MassiveGRID's service extends to the full software stack:

Common Audit Scenarios and How to Handle Them

Understanding what assessors look for helps you prepare effectively. Here are the most common audit scenarios related to TPC-11:

Scenario 1: The CVE Cross-Reference

The assessor pulls a list of all critical and high CVEs published in the past 90 days. They run a vulnerability scan against your environment and check whether each applicable CVE has been patched within the required SLA.

How to pass: Your compliance dashboard shows 95%+ patch compliance with historical deployment logs proving patches were applied within SLA. Any exceptions have documented justifications and compensating controls.

Scenario 2: The Random System Sample

The assessor selects 5-10 systems at random from your asset inventory and performs a deep-dive check on each, examining OS version, installed applications, running services, and firmware versions.

How to pass: Your automated software inventory matches what the assessor finds. No undocumented software, no end-of-life components, no unpatched critical or high vulnerabilities past SLA.

Scenario 3: The Rollback Test

The assessor asks you to demonstrate your rollback procedure. They want to see documentation of a recent rollback event or, failing that, evidence that rollback procedures have been tested.

How to pass: You produce rollback test records from the last quarter showing a successful snapshot restore, with timestamps, before/after system state, and total rollback time.

Scenario 4: The Third-Party Deep Dive

The assessor asks specifically about Java, OpenSSL, or another commonly vulnerable third-party component. They want to know what version is running, when it was last patched, and how you track updates for non-OS software.

How to pass: Your software inventory includes third-party components with version numbers. Your vulnerability scanner covers these components. Patch deployment logs show third-party updates applied within SLA.

Getting Started: From Zero to Compliant

If your current patch management consists of occasional manual updates and no formal process, here is a pragmatic path to TPC-11 compliance:

  1. Inventory everything: Deploy automated discovery to catalog every OS, application, runtime, and firmware version across all in-scope systems. You cannot manage what you do not know about.
  2. Run a baseline vulnerability scan: Identify your current exposure. Expect the results to be uncomfortable -- most organizations are surprised by the number of unpatched vulnerabilities in their environment.
  3. Remediate critical and high findings first: Focus on CVSS 7.0+ vulnerabilities as an immediate priority. These are the findings that will fail your audit.
  4. Implement automated patching: Deploy tools that can automate OS and application patching with scheduled deployment windows. Manual patching does not scale and is not auditable.
  5. Establish the process: Write the patch management policy, define SLAs, create the exception workflow, and assign ownership. The process documentation is as important as the technical implementation.
  6. Generate evidence continuously: Set up compliance dashboards and automated reporting from day one. Retroactively creating evidence for an audit is both difficult and unconvincing.

Alternatively, engage a managed service provider like MassiveGRID that delivers the entire patch management program as a service, from scanning and testing to deployment and reporting, purpose-built for CCC compliance.

Explore the Full CCC-Compliant Infrastructure Package

Patch management is one component of a comprehensive SACS-002 compliance program. The MassiveGRID Aramco CCC-Compliant Infrastructure Package bundles automated patch management with managed firewall, endpoint protection, encrypted backups, VPN, MFA-enforced access controls, logging, and monitoring -- every technical control required for CCC certification in a single managed deployment.

Explore the full CCC-compliant infrastructure package →