ISO 27001 Annex A.9 vs SOC 2 CC6 — What Each Framework Requires for Privileged Access​

The two frameworks approach privileged access from different angles, but the underlying controls they require are more similar than most compliance teams realize.

The overlap is substantial. Eight control areas above — every one of them is addressed once in VaultPAM and produces evidence artifacts that satisfy both frameworks.

Who Needs Which Framework — and Why the Audience Matters​

ISO 27001 is the EU regulatory default. For CEE companies, ISO 27001 is not just a nice-to-have — it is increasingly mandatory:

• NIS2 Directive (transposed into Polish, Czech, Romanian, and other national law by late 2025) explicitly requires risk management and access controls that align with ISO 27001 Annex A. While NIS2 does not mandate ISO 27001 certification, auditors in the region use it as the practical reference.
• EU public sector contracts routinely require ISO 27001 certification as a vendor prerequisite.
• GDPR accountability is easier to demonstrate with an ISO 27001 ISMS in place — the framework's risk treatment structure maps naturally to GDPR Article 32 (security of processing).
• Polish financial sector (KNF supervision) and critical infrastructure operators face direct regulatory pressure that ISO 27001 addresses.

If your customer base is EU-based or you sell to EU government, ISO 27001 is the framework your auditors, customers, and regulators understand.

SOC 2 is the US enterprise sales requirement. If your pipeline includes US enterprise buyers, US SaaS platforms, or US-headquartered companies with procurement security reviews, SOC 2 Type II will come up in the vendor questionnaire. It is not a legal requirement — it is a commercial prerequisite. Enterprise procurement teams have standardized on SOC 2 because it is auditable, time-bounded (Type II covers a 6–12 month period), and issued by recognized CPA firms.

The practical difference: ISO 27001 is driven by regulatory pressure and EU procurement. SOC 2 is driven by US commercial sales motion. Both matter, but they are not the same pressure.

Can You Do Both at Once? Yes — the Overlap is Approximately 70%​

The controls required by ISO 27001 Annex A.9 and SOC 2 CC6 are close enough that a well-designed compliance program can satisfy both simultaneously. The shared work includes:

• Access provisioning and de-provisioning process documentation
• Privileged account inventory and ownership assignment
• MFA enforcement evidence
• Session monitoring and audit log configuration
• Periodic access review procedures
• Incident response procedures touching privileged access

The work that diverges is primarily in the governance layer. ISO 27001 requires a formal Information Security Management System (ISMS) — a documented scope, risk register, Statement of Applicability, and ongoing management review cycle. SOC 2 does not require an ISMS; it requires a Trust Services Criteria opinion from an accredited CPA firm covering a defined period.

From a technical controls standpoint — the actual PAM configuration, session recording setup, access review workflows — the implementation is the same. VaultPAM generates an evidence package for each session and each access grant that satisfies the specific evidence requests from both ISO 27001 auditors (spot-check reviews of access logs) and SOC 2 auditors (population-based sampling of logical access controls over the audit period).

Where companies get into trouble is trying to run both audit programs simultaneously before the ISMS governance layer is mature. The ISO 27001 certification audit typically requires 3–6 months of operating evidence under a documented ISMS. SOC 2 Type II requires 6–12 months. If you start them at the same time, you are managing two audit programs, two sets of auditor requests, and two evidence collection timelines in parallel — which is operationally expensive.

Recommended Sequence for CEE Companies​

For most CEE companies facing both pressures, the practical sequence is:

Phase 1 (Months 1–9): ISO 27001 readiness

Start with ISO 27001 because the regulatory pressure is real and immediate. NIS2 obligations are not theoretical. EU public sector opportunities require it. The ISMS you build for ISO 27001 — risk register, access control policy, asset inventory, audit log procedures — becomes the governance foundation that SOC 2 will stand on.

Configure VaultPAM during this phase: deploy session recording, set up the privileged account vault, enforce MFA, configure access review cycles. Every configuration step produces evidence artifacts that the ISO 27001 auditor will sample.

Phase 2 (Months 6–18): SOC 2 Type II readiness

Start the SOC 2 observation period overlapping with the end of Phase 1. By this point, your technical controls are operational, your ISMS governance is documented, and your team understands evidence collection. The SOC 2 audit primarily adds the CPA firm engagement, the Trust Services Criteria mapping, and the 6–12 month observation window. The underlying controls are already in place.

VaultPAM's audit export functions allow you to pull session-level evidence packages scoped to the SOC 2 observation period, formatted for auditor sampling. The same session records that satisfied your ISO 27001 auditor's spot checks form the population from which your SOC 2 auditor will sample.

Why not SOC 2 first?

If your primary growth market is US enterprise and the regulatory pressure from NIS2 is not yet hitting you operationally, SOC 2 first is a reasonable choice. The controls you build will satisfy ISO 27001 Annex A.9 requirements when you get there. However, for most CEE companies, the regulatory risk from delayed NIS2 compliance outweighs the commercial opportunity cost of delaying SOC 2 by 6–9 months.

Starting With VaultPAM — ISO 27001 and SOC 2 Readiness from a Single Configuration​

The audit-ready architecture in VaultPAM is designed around the intersection of ISO 27001 Annex A.9, SOC 2 CC6, and NIS2 Article 21 requirements. You configure it once — privileged account vault, MFA enforcement, session recording, access review workflows, JIT access with time-bounded sessions — and it produces evidence artifacts formatted for both frameworks.

You do not need two PAM implementations, two audit log formats, or two evidence collection processes. The same session recording that satisfies your ISO 27001 auditor's requirement for A.12.4.3 (administrator and operator logs) is the same record your SOC 2 CPA firm samples for CC6.1 logical access evidence.

Start Free Trial — audit-ready for ISO 27001 and SOC 2 from day one

What Just-in-Time Access Is — and How It Differs from Traditional PAM​

Traditional PAM operates on a vault-and-checkout model. Privileged credentials are stored in a vault. When a sysadmin needs access, they check out credentials, connect to the target system, and check the credentials back in when done. This is better than shared spreadsheets and sticky notes, but it still has a fundamental structural problem: the privileged account itself exists permanently on the target system. The Administrator account on the Windows server, the root account on the Linux host, the sa account on the database — these accounts are always present, always enabled, always a target.

Just-in-time (JIT) access takes a different approach: eliminate the standing account entirely, or at minimum ensure the account is disabled and credentials are rotated immediately before and after each use. Access is provisioned on demand for a specific user, a specific target, and a specific time window. When the window expires, access is automatically revoked — not checked back in, but removed.

The zero standing privileges (ZSP) principle extends this further: no privileged account should have persistent access to any production system. Every privileged session is a temporary grant with a defined start, a defined end, and a complete audit trail. When no session is active, no privileged access exists.

The practical difference between traditional PAM and JIT/ZSP:

• Traditional PAM: The Domain Admins group has 15 members. Credentials are vaulted. Members check out credentials when needed. The accounts exist 24/7 on every domain-joined server.
• JIT PAM: No standing Domain Admins membership. When a sysadmin needs elevated access, they submit a request scoped to a specific server and a specific duration. The system provisions the access, creates the session, records it, and revokes it at the end of the time window.

The attack surface in the traditional model is every moment the account exists, against every system it can reach. The attack surface in the JIT model is the duration of the approved session, against the specific approved target.

Before JIT vs After JIT — A Concrete Scenario​

Before JIT: A senior sysadmin at a 500-person company has been on the team for four years. They are a permanent member of the Domain Admins group and have standing RDP admin access to approximately 200 servers — development, staging, and production. They use this access actively for maybe 20 servers on a regular basis. The other 180 are infrastructure they set up during migrations and have not touched since. Their credentials are in the corporate SSO, their account has never been reviewed for scope reduction, and their access has not changed since they joined.

When their laptop is phished in a targeted attack, the attacker has immediate, persistent, unchallenged access to all 200 servers. The blast radius is the entire infrastructure.

After JIT: The same sysadmin has no standing privileged access. When they need to perform maintenance on a specific production server, they submit a request: "I need RDP admin access to prod-db-03 for 4 hours to apply the quarterly patch." The request is reviewed by their manager and a security team member via a Slack approval workflow. Once approved, the system provisions a time-bounded credential scoped to that specific server. The session is automatically recorded from start to finish. At the end of 4 hours, access is revoked and the credential is rotated.

When their laptop is phished, the attacker has access to whatever active sessions exist at that moment. If no session is currently approved and active, the attacker has no privileged access to any production system. The blast radius is bounded by what was approved and active at the moment of compromise — not the entire infrastructure footprint of the sysadmin's career.

JIT Access and Compliance — How ZSP Maps to NIS2, SOC 2, and ISO 27001​

JIT access and zero standing privileges are not just good security practice — they are increasingly explicit requirements in the compliance frameworks that CEE and European enterprises must satisfy.

NIS2 Article 21 — Least Privilege: NIS2 requires that essential entities implement access control based on least privilege principles. "Least privilege" in the NIS2 context means access should be granted only to the extent necessary to perform a specific task. Standing admin access to 200 servers fails this test by definition — the sysadmin who uses 20 of those servers regularly has standing access to 180 they do not need. JIT access enforces least privilege structurally: access is always scoped to the specific system and time window of the actual need.

SOC 2 CC6.3 — Access Revocation: The SOC 2 Trust Services Criteria require that access is removed promptly when it is no longer required. CC6.3 specifically covers access revocation for terminated employees, role changes, and project endings. JIT access satisfies CC6.3 automatically: access expires at the end of the approved time window without any manual revocation step. The auditor's question — "how do you ensure access is removed when it is no longer needed?" — has a deterministic answer: "It expires automatically; here is the audit log of every session expiry."

ISO 27001 Annex A.9.2 — Access Provisioning: ISO 27001 A.9.2.2 requires a formal access provisioning process, and A.9.2.3 requires that privileged access rights be allocated on a need-to-use basis. "Need-to-use" is the ISO 27001 language for least privilege, and it maps directly to JIT: access should exist when needed and not exist when not needed. A.9.2.5 requires periodic review of user access rights — with JIT access, the review is continuous rather than periodic, because access is re-granted from zero for each session.

The compliance argument for JIT is straightforward: standing privileges are structurally non-compliant with the least-privilege principle that NIS2, SOC 2 CC6.3, and ISO 27001 A.9.2 all require. JIT is the implementation pattern that makes least privilege operationally viable at scale.

How VaultPAM Implements JIT Access​

VaultPAM implements JIT access through four integrated mechanisms:

Approval workflows: When a user requests privileged access to a target system, VaultPAM routes the request to the appropriate approver — manager, security team, or both, depending on the access level and system sensitivity. Approvals can be completed via the VaultPAM web interface or integrated notification channels. The request includes the target system, requested duration, and justification, giving the approver the context to make an informed decision.

Time-bounded sessions: Every approved access grant includes a hard expiry time. The session window is set at approval time — 1 hour, 4 hours, 8 hours, or a custom duration up to the policy maximum. When the session window expires, VaultPAM revokes access automatically. There is no manual step, no reminder email, no dependency on the user logging out. The access simply stops existing.

Auto-expiry and credential rotation: For RDP and SSH sessions, VaultPAM provisions a session-specific credential at the start of the approved window and rotates it at expiry. The credential that existed for the approved session no longer works after expiry. An attacker who captures the credential mid-session cannot reuse it after the window closes.

Audit trail: Every JIT request — submission, approval or denial, session start, session duration, session recording, and expiry — is recorded in VaultPAM's immutable audit log. The audit trail includes the approver identity, the approval timestamp, the justification text, and a complete recording of the session activity. This is the evidence package that satisfies NIS2 audit requests, SOC 2 auditor sampling, and ISO 27001 spot-check reviews.

See VaultPAM JIT access in action — eliminate standing privileges in your environment

This guide cuts through the noise: here is exactly what NIS2 Article 21 requires for privileged access, and here is how each requirement maps to a concrete implementation step.

What NIS2 Article 21 Actually Requires​

Article 21 of the NIS2 Directive requires "appropriate and proportionate technical, operational and organizational measures to manage the risks posed to the security of network and information systems." For privileged access, this translates into ten specific controls that Polish regulators will examine during inspections:

1. Multi-factor authentication on all privileged accounts — every administrative account must require a second factor. SMS OTP does not satisfy the requirement for high-assurance access; TOTP or hardware tokens (WebAuthn/FIDO2) are expected.

2. Session recording for privileged sessions — every RDP, SSH, and administrative web session must be recorded with tamper-proof integrity. The recording must be retrievable for audit purposes for at least 12 months.

3. Audit trail and event logging — every access event (login, session start, session end, command executed, file transferred) must be logged with a tamper-evident timestamp.

4. Least privilege enforcement — users must only have the access they need, when they need it. Standing administrative rights on production systems are not compliant.

5. Just-in-Time (JIT) access — privileged access should be time-boxed. Access is granted for a specific session or time window and automatically revoked afterward.

6. Approval workflows for sensitive access — access to critical systems should require documented approval from a second authorized person before the session begins.

7. Credential vault with automatic rotation — privileged passwords must not be shared, written down, or stored in spreadsheets. Credentials must be stored in an encrypted vault and rotated automatically.

8. Zero standing access to production credentials — users must connect through a brokered session; they must not see or receive the actual password.

9. Access review process — privileged access rights must be reviewed and recertified at regular intervals (quarterly is typical for high-sensitivity systems).

10. Incident response evidence preservation — session recordings and audit logs must be preserved in a way that they can be produced in response to a security incident or regulatory investigation.

How VaultPAM Maps to Each Article 21 Control​

Implementation Timeline​

Not everything needs to happen on day one. Here is a realistic timeline for a Polish enterprise starting from scratch:

First 30 days — Stop the bleeding​

• Deploy VaultPAM in your environment (one afternoon, no agents to install)
• Migrate your highest-risk admin accounts to VaultPAM session brokering
• Enable TOTP MFA for all accounts that access production systems
• Disable direct RDP from the internet (expose access through VaultPAM only)

Why this first: Direct internet-exposed RDP is the single most common initial access vector in ransomware attacks. Eliminating it reduces your risk exposure immediately, even before the full compliance picture is complete.

Days 31–90 — Build the compliance posture​

• Enroll all privileged accounts in the vault (disable knowledge of production passwords by operators)
• Configure automatic credential rotation for all production accounts
• Enable session recording for all RDP, SSH, and administrative web sessions
• Set up approval workflows for your five most sensitive production targets
• Export the first access review report for your CISO

Before April 2027 — Close the compliance gaps​

• Complete JIT access policy rollout across all production targets
• Implement access review process with quarterly cadence
• Document your privileged access management policy (VaultPAM produces the evidence; you write the policy that references it)
• Run an internal audit simulation: pull a session recording, produce an audit log, demonstrate MFA configuration to an auditor-level reviewer
• Engage your external auditor or CISO for a pre-assessment walkthrough

The Management Liability Question​

One aspect of the Polish UKSC implementation that many IT teams have not yet communicated upward: Article 32 of the NIS2 Directive makes management personally liable for failing to implement required security measures. "The IT team was working on it" is not a defense if regulators find that privileged access controls were not in place.

If your organization is subject to NIS2 (and most Polish enterprises in essential and important sectors are), the board needs to see a credible implementation plan with milestones, not a vague commitment to "improve security."

See how VaultPAM satisfies NIS2 Article 21 out of the box. Every required control — session recording, MFA, JIT access, approval workflows, credential vault — ships in the base product, hosted in GCP europe-central2 (Warsaw, Poland) for data residency compliance.

Start Free Trial

The Five Vendors​

Shortlisting PAM vendors in 2026 means navigating a market that spans US cloud-native startups, EU-regulated incumbents, and a new wave of EU-founded challengers built specifically for the NIS2 era. Here is where each of the five vendors in this comparison sits.

US-based Vendor A is a US-headquartered cloud-native PAM platform that built its reputation on SSH and Kubernetes access management. It has since expanded to Windows Desktop (RDP) and database access. Its pricing model is usage-based — Monthly Active Users plus protected resources — which makes it attractive for engineering-heavy organisations with predictable infrastructure. It does not publish EU-specific data residency guarantees on its public website.

US-based Vendor B is a US-headquartered multi-protocol PAM platform with broad coverage: databases (PostgreSQL, MySQL, MSSQL, MongoDB), servers (SSH, RDP), Kubernetes, and cloud services in a single proxy model. It was acquired by a major legacy PAM vendor in early 2026. Pricing is contact-sales only across all tiers. EU data residency is not documented publicly.

EU-based Vendor C is a French publicly-listed company with dual BSI and ANSSI certification — the only vendor in this comparison holding both German and French national security certifications. It targets multi-protocol PAM with both on-premises and cloud deployment options, and has a strong go-to-market presence in France and Germany, including procurement via French government framework agreements. Pricing is contact-sales.

EU-based Vendor D is a Polish company headquartered in Warsaw, Series A funded in 2025. It focuses on agentless PAM with RDP session recording and has positioned itself explicitly around NIS2 compliance. As a Warsaw-headquartered company, it shares the same jurisdiction as VaultPAM. Pricing is contact-sales.

EU-based Vendor E is a Finnish publicly-listed company (Nordic stock exchange) that takes a certificate-based, no-vault approach to PAM: ephemeral certificates replace stored credentials entirely, so there is no privileged credential vault to protect. It is SSH-primary with RDP support added. It is the only vendor in this comparison with online purchasing available at published tier prices.

How Each PAM Handles Your Traffic​

Architecture is not an implementation detail — it determines what your audit trail looks like, whether an agent needs to be installed on every target server, and whether session recordings will satisfy a regulator who asks to see them.

What the Architecture Differences Actually Mean​

The credential model choice has compliance consequences that are easy to miss in a feature comparison.

Certificate-only (no vault) PAM eliminates the risk of stored credential compromise — there are no stored credentials to steal. EU-based Vendor E's architecture is genuinely innovative in this respect. However, it also means there is no credential access audit trail for some regulatory frameworks. If an auditor asks "who had access to the Windows Administrator password on this server between March 1 and March 31," the answer in a certificate-only model is a certificate issuance log — not a credential vault access log. Some regulators and audit frameworks accept this; others expect a traditional vault access audit trail. Know which your auditors expect before selecting this model.

Screenshot-based versus protocol-level RDP recording is a distinction that matters for NIS2 Article 21. Screenshot-based recording captures what a user saw but does not capture the underlying RDP command and control stream. Protocol-level recording captures the full session: keystrokes, clipboard transfers, file transfers, and display output at the protocol layer. The difference becomes significant when an incident response team needs to reconstruct exactly what happened in a privileged session — a screenshot sequence may not be sufficient. VaultPAM, EU-based Vendor C, and EU-based Vendor D all document protocol-level or equivalent recording; US-based Vendor A documents screenshot-based recording for Windows Desktop sessions specifically.

Agentless versus agent-based affects deployment overhead at scale. For organisations with hundreds of Windows servers, deploying and maintaining an agent on each target adds operational cost. Agentless models (VaultPAM, EU-based Vendor D, US-based Vendor B) connect through a central proxy without touching the target server's software stack.

Data Sovereignty, Certifications, and NIS2 Compliance Depth​

EU security posture is increasingly a procurement gate — not a nice-to-have. For organisations subject to NIS2, GDPR, or sector-specific regulations (DORA, UKSC, Polish cybersecurity act), the vendor's jurisdiction and certification posture determine whether the tool is even on the shortlist.

The CLOUD Act Problem for EU Buyers​

US-headquartered companies — regardless of where they host their data — are subject to the US Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018. Under CLOUD Act, a US company can be compelled by a US government order to disclose data it holds or controls, even when that data is stored in an EU data centre.

This is not a theoretical risk. For NIS2-scoped entities in critical infrastructure sectors (energy, transport, healthcare, financial infrastructure), procurement of cloud services from US-HQ vendors now routinely includes a legal review of CLOUD Act exposure. For organisations that have completed this review and accepted the risk, US-based vendors remain viable. For organisations where the legal or compliance team has flagged CLOUD Act as a procurement gate, only EU-HQ vendors pass.

EU-based Vendors C, D, and E are incorporated in EU member states and do not have direct CLOUD Act exposure as companies. VaultPAM is also EU-incorporated (Poland), but its cloud infrastructure runs on GCP europe-central2 — a product of Google LLC, a US company. Whether CLOUD Act could reach VaultPAM customer data via a request directed at Google is a legal question; procurement teams in critical infrastructure sectors should seek counsel. In practice, standard cloud data processing agreements and EU data protection frameworks provide significant procedural protections against such requests, and Google publishes a Government Requests Transparency Report documenting its challenge rate.

BSI and ANSSI Certification​

EU-based Vendor C is the only vendor in this comparison with BSI (Bundesamt für Sicherheit in der Informationstechnik, Germany) and ANSSI (Agence nationale de la sécurité des systèmes d'information, France) dual certification. For procurement into German federal government infrastructure, critical national infrastructure in France, or any organisation that has a contractual requirement for BSI or ANSSI certification, EU-based Vendor C is the only option in this comparison that qualifies. No other vendor reviewed here has achieved this certification level.

NIS2 Article 21 Documentation​

NIS2 Article 21 requires organisations to implement "appropriate and proportionate technical and organisational measures" including privileged access controls, multi-factor authentication, and session recording. Auditors increasingly ask vendors to provide a control mapping that shows how their product implements each Article 21 sub-requirement.

VaultPAM publishes an Article 21 control mapping as part of its product documentation. US-based Vendor B has published NIS2 content at the blog/marketing level. The remaining vendors in this comparison do not publicly document an Article 21 control mapping as of May 2026.

What You Actually Pay​

Enterprise PAM pricing is almost universally opaque. The table below reflects what each vendor publicly documents.

VaultPAM and EU-based Vendor E are the only two vendors in this comparison that publish pricing on their public website and offer a path to start without a sales conversation. Every other vendor in this comparison requires procurement engagement before any pricing information is available.

The Real Cost Is Not the Licence Fee​

List price is the least informative number in a PAM evaluation. The total cost of ownership depends on:

• Agent deployment and maintenance costs — for agent-based architectures, the ongoing cost of deploying, updating, and troubleshooting agents across all target servers is real operational overhead. For a 500-server environment, this can exceed the licence cost in staff time over a three-year contract.
• Session storage costs — session recordings at full fidelity generate significant storage volume. Vendors that include storage in the licence (VaultPAM Starter includes 50 GB) are easier to budget for than those that charge separately for recording storage.
• AD/LDAP integration effort — nearly all PAM platforms require integration with Active Directory for user identity. The integration complexity varies significantly between vendors, and poor integration design creates ongoing helpdesk burden.
• Support SLA costs — the difference between business-hours email support and 24/7 phone support is often a separate line item or tier upgrade. For PAM platforms protecting critical infrastructure, the support SLA is not optional.

The Right Tool for Your Situation​

No single PAM platform is the right answer for every European enterprise. The architecture choices, jurisdiction, certification posture, and pricing model all create natural fits for specific buyer profiles.

Polish NIS2-scoped entity — particularly in critical infrastructure or essential services regulated under the Polish UKSC transposition. You need a hard EU data residency guarantee (not a contractual option that defaults elsewhere), a published Article 21 control mapping, RDP session recording with tamper-evident chain of custody, and support available in a compatible timezone. VaultPAM (Warsaw-headquartered, GCP europe-central2 data residency, Article 21 mapping published) and EU-based Vendor D (also Warsaw-headquartered, NIS2 focus) are the two vendors in this comparison that meet this profile. VaultPAM publishes pricing and offers a free trial; EU-based Vendor D requires a sales conversation.

French or German critical infrastructure with BSI or ANSSI contractual requirement. This narrows the field to one option: EU-based Vendor C. It is the only vendor in this comparison with dual BSI and ANSSI certification. If your procurement contract or sector regulator requires this certification level, no other vendor in this comparison qualifies. The trade-off is contact-sales-only pricing and a more complex on-prem deployment model.

Cloud-native technology company with SSH and Kubernetes as the primary access surface. If your infrastructure is Linux-heavy, Kubernetes-first, and hosted on a major cloud provider, US-based Vendor A's core product is genuinely strong. Its SSH and Kubernetes access management is more mature than its Windows/RDP stack. Accept the CLOUD Act risk if your legal team has cleared it, accept the usage-based pricing model, and verify the EU data residency position in writing before signing.

Security team that wants to eliminate stored credentials entirely — certificate-only PAM. If your security architecture rationale is "we do not want a credential vault because vaults are targets," EU-based Vendor E's certificate-based model is the only option in this comparison that matches this philosophy. It is SSH-primary, so verify RDP recording capability specifically before procurement. It is also the only EU vendor in this comparison with both public pricing and online purchasing — the fastest path to a proof of concept.

CTA​

VaultPAM is built for European enterprises with RDP-heavy infrastructure and NIS2 obligations. Publicly documented pricing, a 14-day free trial, and GCP europe-central2 data residency — no standard contractual clauses required for EU data processing.

Start Free Trial

The 12-Item Checklist​

Work through these in order. Items 1–3 are critical; address them before anything else.

1. Exposed RDP port (3389) directly on the internet​

Problem: Your Windows servers accept RDP connections on port 3389 from the public internet.

Risk: Attackers continuously scan for open port 3389. Within hours of a new server coming online, it is receiving brute-force and credential-stuffing attacks. This is the most common ransomware initial access vector in enterprise environments.

Fix: Remove the firewall rule that allows inbound 3389 from the internet. Access Windows servers only through a PAM solution (like VaultPAM) that brokers the session — the RDP port stays closed on the server, and the connection is established outbound through the connector.

2. Shared admin credentials across servers​

Problem: Your team uses a shared Administrator account (or admin, or a single named account) across multiple servers, and multiple people know the password.

Risk: When one person leaves, you face the impossible choice of rotating the password and disrupting everyone else, or leaving the ex-employee's access intact. When you have an incident, you cannot determine who performed which action because all activity is attributed to a shared account.

Fix: Move to individual named accounts for all privileged access. Use a credential vault to store and rotate server credentials automatically. Use session brokering so users connect without receiving the actual password — the vault holds it.

3. No MFA on privileged accounts​

Problem: Administrators authenticate to production systems with username and password only.

Risk: A single phishing email, credential dump, or reused password gives an attacker full administrative access. MFA is the single highest-impact control for stopping credential-based attacks.

Fix: Require TOTP (Google Authenticator, Authy) or hardware tokens (YubiKey, Touch ID, Windows Hello) for every privileged account. Verify enforcement — policy documents do not count; demonstrate that a login attempt without MFA is rejected.

4. No session recording​

Problem: When privileged sessions occur, there is no record of what happened inside the session.

Risk: Post-incident forensics are impossible. Auditors cannot verify what actions were taken. Insider threats leave no evidence trail. Ransomware attackers who abuse admin credentials cannot be traced past the login event.

Fix: Route all privileged sessions through a PAM solution that records full session video and activity logs (commands executed, files transferred, clipboard contents). Store recordings with tamper-proof integrity (hash chains) for at least 12 months.

5. Standing admin privileges (no JIT access)​

Problem: Administrators have 24/7/365 privileged access to production systems, even when they are not performing an administrative task.

Risk: An attacker who compromises an administrator's workstation or credentials has immediate and persistent access to production. The attack surface is always maximum.

Fix: Implement Just-in-Time (JIT) access. Privileges are granted for a specific task and time window, then automatically revoked. Between tasks, the account has no privileged access — or no active account at all.

6. No audit log forwarding​

Problem: Server event logs (Windows Event Log, Linux auth log) sit on the server where they can be cleared by an attacker who achieves administrative access.

Risk: An attacker with admin access can clear logs and erase evidence of their presence. During incident response, critical forensic data may be missing.

Fix: Forward all privileged access events to a centralized SIEM or immutable log store immediately upon generation. Ensure the log forwarder runs as a service that cannot be stopped without triggering an alert.

7. Unrotated credentials in shared vaults or spreadsheets​

Problem: Production passwords are stored in a shared spreadsheet, a shared password manager with multiple users, or an IT documentation tool — and have not been rotated in months or years.

Risk: Every person who has ever had access to that spreadsheet or password manager is a potential threat. Credentials shared in plaintext are credentials that will eventually leak.

Fix: Move all production credentials to a vault with automatic rotation. Set rotation schedules appropriate to sensitivity (daily for critical production accounts, weekly for others). Configure the vault to rotate credentials after each checkout.

8. No approval workflow for sensitive targets​

Problem: Any administrator can access any server at any time without a second person knowing or approving.

Risk: Lateral movement by an insider threat or compromised admin account is unchecked. Accidental changes to critical systems have no second-pair-of-eyes control.

Fix: Implement approval workflows for your five most sensitive production targets. Access requests require documented approval from a second authorized person before the session begins. VaultPAM records the request, the approval, and every action taken during the approved session.

9. Default admin account names (Administrator, admin, root)​

Problem: Your servers use the default built-in administrator account names.

Risk: Credential-stuffing attacks target default account names because they are predictable. Every Windows server has an Administrator account; attackers know to try it first.

Fix: Rename the built-in Windows Administrator account on all servers. On Linux, disable direct root SSH login (PermitRootLogin no in sshd_config). Create named administrative accounts for legitimate use. Store credentials in a vault.

10. No timeout on idle sessions​

Problem: RDP sessions remain active indefinitely when the user steps away from their desk without locking or disconnecting.

Risk: An unattended active session is an open door. Physical tailgating or remote access to the admin's workstation gives full access to every system the admin is connected to.

Fix: Configure session timeout policies — disconnect idle sessions after 15 minutes, log off disconnected sessions after 30 minutes. Enforce at both the client (GPO) and server level. VaultPAM enforces session timeouts at the PAM layer regardless of client configuration.

11. VPN-only access control (no PAM layer)​

Problem: Your access control model is: "if you are on the VPN, you can RDP to any server you have credentials for."

Risk: VPN is network-layer access control. It does not restrict which servers a user can reach, does not enforce least privilege, does not record sessions, and does not require MFA per session. A compromised VPN credential gives an attacker access to your entire internal network.

Fix: Add a PAM layer on top of the VPN (or replace VPN-based access entirely). Users authenticate to the PAM solution, which enforces policy-based access to specific targets, requires MFA, and records every session. The target servers are not reachable from the VPN — only from the PAM connector.

12. No access review process​

Problem: Privileged access rights are granted but never reviewed. Users accumulate access over time; leavers may retain access for months after departure.

Risk: Privilege creep is a top audit finding and a real security risk. Dormant accounts with privileged access are high-value targets — attackers look for accounts that have not logged in recently (no one is watching).

Fix: Implement a quarterly access review process. Export the complete list of privileged accounts and their access rights. Have a designated reviewer confirm that each access is still required and appropriately scoped. Revoke access that cannot be justified. Document the review with date, reviewer name, and outcome.

Where to Start​

If you are preparing for a pentest, prioritize items 1, 2, and 3 first — they are the most likely initial-access findings and the highest risk. Items 4, 5, and 6 are the most likely post-exploitation findings. Items 7–12 are the most common compliance audit findings.

All 12 items are addressed by deploying a PAM solution. The pentest findings list does not get shorter over time without one — it gets longer as your environment grows.

VaultPAM addresses all 12 of these findings in a single afternoon deployment. No agents to install. No firewall changes needed. Sessions are brokered through outbound-only connectors; port 3389 stays closed.

Start Free Trial — see how VaultPAM eliminates the top RDP pentest findings from your environment.

CC6 is where auditors spend the most time and where companies most often receive exceptions. It covers who has access to your systems, how that access is controlled, how it is monitored, and how it is reviewed. If your privileged access management answer is "we use VPN plus RDP with shared admin credentials," you are not going to pass.

Here is exactly what CC6 requires, what auditors ask for, and how to produce the evidence.

CC6.1, CC6.2, CC6.3, CC6.6 — What Each Requires in Plain English​

CC6.1 — Logical Access Security​

The requirement: logical access to your systems, infrastructure, and data is restricted to authorized users.

In practice, this means:

• Every user who accesses a production system has a documented reason for that access
• Access is provisioned through a defined process (not ad hoc)
• Access is removed promptly when a user leaves or changes roles
• Privileged access (admin, root, DBA) is tracked separately and held to a higher standard

The evidence auditors want: a complete inventory of who has privileged access to what, how it was provisioned, and when it was last reviewed.

CC6.2 — Identification and Authentication​

The requirement: users are authenticated before accessing systems, and authentication is sufficiently strong for the sensitivity of the resource.

In practice, this means:

• MFA is required on all accounts with privileged access
• Passwords meet complexity and rotation requirements
• Shared accounts (shared Administrator, shared root) are eliminated or tightly controlled
• Service accounts are inventoried and access is reviewed

The evidence auditors want: MFA enrollment screenshots, account inventory exports, evidence that shared admin accounts have been eliminated or have compensating controls.

CC6.3 — Access Removal​

The requirement: access is removed when it is no longer needed (termination, role change, project end).

In practice, this means:

• You have a documented offboarding process that includes revoking privileged access
• Access revocation happens within a defined timeframe (24-48 hours for production access)
• You can demonstrate that terminated users no longer have active sessions or credentials

The evidence auditors want: offboarding tickets showing access revocation steps, before/after screenshots of access rights.

CC6.6 — Logical Access Restrictions​

The requirement: transmission of data is encrypted, and logical access restrictions are in place to prevent unauthorized access.

In practice, this means:

• All administrative connections are encrypted in transit
• Access to sensitive systems is restricted to authorized endpoints or networks
• Session activity is monitored and logged

The evidence auditors want: network diagrams showing encrypted channels, session logs showing administrative activity.

What Auditors Actually Ask For​

When a SOC 2 auditor examines CC6, they typically request the following evidence:

For CC6.1 (access inventory):

• Spreadsheet or system export showing all users with privileged access, the systems they can access, and the business justification
• Evidence that access was approved (email, ticket, approval workflow screenshot)
• Access review records showing quarterly or annual recertification

For CC6.2 (authentication):

• Screenshot of MFA enrollment for administrative accounts
• Password policy documentation and evidence it is enforced
• List of service accounts and evidence of inventory

For CC6.3 (access removal):

• Sample offboarding tickets (typically 3-5 examples from the audit period)
• Evidence that privileged access was revoked within SLA
• HR system integration or manual verification records

For CC6.6 (session monitoring):

• Session logs showing administrative activity (who logged in, when, to what system, what they did)
• Evidence that sessions are recorded
• Network diagram showing encryption in transit

The evidence must cover the full audit period (typically 12 months for a Type II audit). Auditors will sample events across that period — you cannot rely on evidence from the last two weeks before audit fieldwork.

Common CC6 Failures and How to Avoid Them​

Shared admin credentials The most common CC6 finding. "We use the shared Administrator account because some systems don't support individual accounts" is not an acceptable control. VaultPAM solves this: users connect through brokered sessions without receiving the credential. The vault holds the password; audit logs show exactly which user initiated each session.

MFA not enforced on all privileged accounts Organizations often have MFA on their corporate email but not on direct server access (RDP, SSH). Auditors check this specifically. Every privileged session must require MFA.

No access review evidence Many organizations conduct access reviews informally. Auditors want documented evidence: who reviewed, what was reviewed, when, and what actions were taken. "We did a review in Q3" without a ticket, spreadsheet, or report is not evidence.

Access not revoked promptly The gap between an employee leaving and their access being revoked is a recurring finding. If your offboarding process takes a week, and privileged access is included in that same queue, you have a CC6.3 problem.

Session logs that are incomplete or inaccessible Retaining session logs is only half the answer. Auditors want to see that you can retrieve specific events and that the logs are complete and tamper-evident. Logs in disparate silos (Windows Event Log on each server, SSH auth logs on each Linux box) without central aggregation are difficult to present as evidence.

How VaultPAM Produces Audit-Ready CC6 Evidence Automatically​

VaultPAM is designed around the assumption that your auditor is reading over your shoulder. The evidence it produces maps directly to what CC6 requires:

The access review process is supported by VaultPAM's audit log exports: you can produce a complete report of every privileged session in the last quarter, sorted by user and target, in minutes. Present that to your auditor alongside the access policy configuration and the MFA enrollment screenshot — that is your CC6 evidence package.

Building toward SOC 2 Type II readiness? VaultPAM produces audit-ready evidence for CC6 controls automatically — session recordings, access logs, MFA enforcement, and policy configuration are all reportable from a single dashboard.

Download our SOC 2 compliance summary for a complete mapping of VaultPAM controls to SOC 2 Trust Service Criteria.