Map controls, not marketing.
Zerostand supports the controls below and helps you evidence them. Compliance remains your responsibility; the framework text is the authority.
Information only, not legal advice or a certification. Not affiliated with or endorsed by any body named here. The official framework text prevails. Mappings as at 14 October 2026; framework editions as named in each section. Full notice.
Eleven frameworks, control by control
Pick the one your auditor or regulator uses. Each tile opens the table of controls and how Zerostand supports them.
ISO/IEC 27001:2022
Annex A controls on access, identity, authentication and logging.
View mapping →SOC 2
AICPA Trust Services Criteria, common criteria CC6 and CC7.
View mapping →NIST SP 800-53 Rev. 5
Access control, identification and authentication, and audit families.
View mapping →PCI DSS v4.0.1
Requirements 7, 8 and 10: access review, authentication and audit logging.
View mapping →HIPAA Security Rule
Technical safeguards in 45 CFR § 164.312.
View mapping →DORA
RTS 2024/1774, Article 21: access control for EU financial entities.
View mapping →NIS2
Directive Article 21(2) and the implementing regulation on privileged accounts.
View mapping →BNM RMiT
Bank Negara Malaysia, paragraphs S 10.53 to S 10.57 on access control.
View mapping →MAS TRM
Monetary Authority of Singapore, section 9: user, privileged and remote access.
View mapping →RBI Directions 2026
Reserve Bank of India: audit trails, user access control and privileged access.
View mapping →APRA
The 2024 letter on common cyber resilience weaknesses: privileged access.
View mapping →ISO/IEC 27001:2022 Annex A
Information security management systems — Requirements, Annex A controls on access, identity, authentication and logging. Control titles only; the full text is in the standard, which is paywalled.
Official source: iso.org/standard/27001 ↗| Control | Control title | How Zerostand supports it |
|---|---|---|
| A.5.15 | Access control | Policy as code decides every access for people and workloads; grants expire on their own; step-up MFA per target where you require it. |
| A.5.16 | Identity management | People provisioned by SCIM from your identity provider; workloads enrolled by trust rules with platform attestation; one identity per actor in the audit log. |
| A.5.17 | Authentication information | Vaulted passwords rotated on a schedule, verified and reconciled; a reveal needs a reason, is audited and is followed by a rotation; short-lived certificates and tokens where the target allows. |
| A.5.18 | Access rights | Access requests with approval chains and expiry; recertification campaigns with exportable evidence; an entitlements report and an access graph. |
| A.8.2 | Privileged access rights | Exclusive checkout of shared accounts; break-glass limited to named people and capped in time; privileged sessions brokered and recorded by default. |
| A.8.5 | Secure authentication | Single sign-on over OIDC, TOTP in Zerostand, and step-up MFA per target; phishing-resistant methods through your identity provider. |
| A.8.15 | Logging | A hash-chained, tamper-evident audit log you can verify, forwarded to your SIEM by webhook or syslog; session recordings with retention you set. |
Control titles from ISO/IEC 27001:2022 Annex A. Zerostand holds no ISO/IEC 27001 certification.
AICPA Trust Services Criteria (SOC 2)
2017 Trust Services Criteria with revised points of focus (2022), common criteria CC6 and CC7. A SOC 2 report is an auditor's examination of your organisation; a product cannot be "SOC 2 compliant".
Official source: aicpa-cima.com (login required) ↗| Criterion | What it asks | How Zerostand supports it |
|---|---|---|
| CC6.1 | Logical access security software, infrastructure and architectures over protected information assets, to protect them from security events. | Short-lived, policy-checked access to servers, databases and applications; vaulted credentials envelope-encrypted once you configure a key-encryption key. |
| CC6.2 | Register and authorise users before issuing credentials, and remove credentials when access is no longer authorised. | Users provisioned and deprovisioned by SCIM from your identity provider; access requests approved before a credential is issued; grants expire on their own. |
| CC6.3 | Authorise, modify or remove access based on roles and responsibilities, considering least privilege and segregation of duties. | Policy as code per target and role; approval chains; recertification campaigns with exportable evidence; posture findings for over-privileged accounts. |
| CC6.6 | Logical access security measures against threats from sources outside the system boundaries. | Brokered SSH, RDP, database and web sessions behind single sign-on, with step-up MFA where you require it; TLS by default on Zerostand's listeners and gateways. |
| CC7.2 | Monitor system components for anomalies indicating malicious acts, natural disasters or errors, and analyse them to decide whether they are security events. | Every grant, approval, rotation and session in the audit log, forwarded to your SIEM; a rotation-health view and posture findings for orphaned, stale and over-privileged accounts. |
NIST SP 800-53 Rev. 5
Security and Privacy Controls for Information Systems and Organizations (Release 5.2.0), families AC, IA and AU. Bracketed values in the controls are organisation-defined.
Official source: csrc.nist.gov ↗| Control | What it asks | How Zerostand supports it |
|---|---|---|
| AC-2 | Account managementManage system accounts through their lifecycle: approvals to create, authorisation based on valid need, monitoring of use and periodic review; change shared or group authenticators when members leave. | Access requests with approvals; discovery of accounts outside any safe; recertification campaigns; shared-account passwords rotated on a schedule and, where you turn it on for the safe, on check-in. |
| AC-2(2) | Automated temporary and emergency account managementAutomatically remove or disable temporary and emergency accounts after an organisation-defined period. | Grants, SSH certificates, tokens and dynamic database logins expire automatically; break-glass access is capped in time. |
| AC-6 | Least privilegeAllow only the access users, or processes acting for them, need for their assigned tasks. | Policy as code scoped per target and role; access granted for a window and expiring on its own. |
| AC-6(5) | Privileged accountsRestrict privileged accounts to defined personnel or roles. | Privileged accounts vaulted in safes with named members; exclusive checkout; break-glass limited to pre-listed people. |
| AC-6(9) | Log use of privileged functionsLog the execution of privileged functions. | Every grant, reveal, rotation, break-glass and administrative change in the hash-chained audit log; sessions recorded by default; SQL statements logged for PostgreSQL and MySQL through the gateway. |
| AC-17 | Remote accessSet usage restrictions and connection requirements for each type of remote access, and authorise each type before allowing connections. | Remote sessions brokered through Zerostand over SSH, RDP, database and web gateways, with MFA where you require it and recording by default. |
| IA-2(1) | Multi-factor authentication to privileged accountsImplement multi-factor authentication for access to privileged accounts. | TOTP in Zerostand or your identity provider's MFA, plus step-up per target before a privileged session. |
| IA-5 | Authenticator managementManage authenticators: sufficient strength, protection from disclosure and modification, change on a defined schedule or event, and change for shared accounts when membership changes. | Vaulted passwords generated to a per-platform policy, rotated on a schedule, verified and reconciled; rotation on check-in where you turn it on for the safe. |
| AU-9 | Protection of audit informationProtect audit information and logging tools from unauthorised access, modification and deletion, and alert on any such attempt. | A hash-chained, tamper-evident audit log you can verify; forwarded to your SIEM by webhook or syslog so a copy sits outside Zerostand. |
| AU-14 | Session auditProvide the capability for defined users or roles to record, view, hear or log the content of user sessions, used in line with legal counsel and applicable law. | SSH, RDP, database and web sessions recorded by default and replayable; SSH watched live; any session terminated; retention you set. |
PCI DSS v4.0.1
Requirements 7, 8 and 10: access review, authentication of users and of system and application accounts, and audit logging.
Official source: PCI SSC document library ↗| Requirement | What it asks | How Zerostand supports it |
|---|---|---|
| 7.2.4 | Review all user accounts and access privileges, including third-party and vendor accounts, at least once every six months; address inappropriate access; management acknowledges access remains appropriate. | Recertification campaigns with reminders, escalation and exportable evidence of every decision; the same requests and reviews cover third-party accounts. |
| 8.2.2 | Group, shared or generic IDs used only by exception: time-limited, justified, approved by management, individual identity confirmed and every action attributable. | Shared accounts vaulted and checked out by one named person at a time with a reason, approval and expiry; every session attributed to that person. |
| 8.4.2 | MFA for all non-console access into the cardholder data environment. | MFA before brokered sessions where you require it: TOTP in Zerostand or your identity provider's MFA, plus step-up per target. |
| 8.6.1 | Interactive use of system or application accounts only in exceptional circumstances, time-limited, justified, approved, with the individual confirmed and every action attributable. | Exclusive checkout of a shared account with a reason, approval and expiry; rotation on check-in, which you turn on per safe; the session recorded and attributed to the person who signed in. |
| 8.6.2 | Passwords for application and system accounts that can be used for interactive login are not hard-coded in scripts, configuration or property files, or custom source code. | Workloads attest with their platform identity and receive credentials that expire; dynamic database credentials and app-to-app retrieval replace passwords in files. |
| 8.6.3 | Application and system account passwords protected against misuse: changed at the frequency set by a targeted risk analysis and on suspected or confirmed compromise, with complexity suited to that frequency. | Safes with scheduled rotation, verification and reconciliation per platform policy; rotation on demand; dynamic credentials where a static password is not needed at all. |
| 10.2.1.2 | Audit logs capture all actions by anyone with administrative access, including any interactive use of application or system accounts. | Every grant, reveal, rotation, break-glass and administrative change in the hash-chained audit log, with the actor on every event a person or workload performs; sessions recorded by default. |
Zerostand holds no PCI DSS assessment or validation; this table does not state or imply PCI DSS compliance.
HIPAA Security Rule 45 CFR § 164.312
Technical safeguards, as in force (last amended 2013). The January 2025 proposed rule is not final and is not cited here.
Official source: ecfr.gov ↗| Standard | What it asks | How Zerostand supports it |
|---|---|---|
| § 164.312(a)(1) | Access controlTechnical policies and procedures that allow access to ePHI systems only to persons or software programs granted access rights. | Policy as code decides which people and workloads reach a system; grants expire on their own; exclusive checkout of shared accounts. |
| § 164.312(a)(2)(ii) | Emergency access procedureProcedures for obtaining necessary ePHI during an emergency. | Break-glass access for named people, capped in time, needing a reason and raising its own audit event, can form part of your emergency access procedure. |
| § 164.312(b) | Audit controlsMechanisms that record and examine activity in systems that contain or use ePHI. | A hash-chained audit log of every grant, session, reveal and change, forwarded to your SIEM; sessions recorded by default and replayable. |
| § 164.312(d) | Person or entity authenticationProcedures to verify that a person or entity seeking access to ePHI is the one claimed. | Single sign-on through your identity provider, TOTP and step-up MFA per target for people; platform attestation for workloads. |
DORA RTS on ICT risk management 2024/1774
Commission Delegated Regulation (EU) 2024/1774, Article 21, access control: the access-control policy required of financial entities under Title II (not the simplified framework).
Official source: EUR-Lex, OJ L 2024/1774 ↗| Control | What it asks | How Zerostand supports it |
|---|---|---|
| Art. 21(a) | Access rights assigned on need-to-know, need-to-use and least-privilege principles, including for remote and emergency access. | Access scoped per target and role, granted for a window and expiring on its own; emergency access limited to pre-listed people, capped in time and recorded as its own audit event. |
| Art. 21(c) | Limit generic and shared accounts; users identifiable for their actions. | Shared accounts live in safes and are checked out by one named person at a time; every session, reveal and rotation names the actor. |
| Art. 21(e)(ii) | Privileged, emergency and administrator access assigned on a need-to-use or ad-hoc basis for all ICT systems; dedicated administrative accounts where possible, and automated privileged access management where feasible and appropriate. | Requests with approval chains and expiry; online break-glass and a sealed offline export encrypted to named key-holders; all of it in the audit log. |
| Art. 21(e)(iv) | Access rights updated when needed and reviewed at least yearly, or at least every six months for ICT systems supporting critical or important functions. | Recertification campaigns on the schedule you set, with reminders, escalation and exportable evidence; an entitlements report of what stands between campaigns. |
| Art. 21(f)(ii) | Strong authentication for remote access, privileged access, and access to ICT assets that support critical or important functions or are publicly accessible. | MFA where you require it (TOTP in Zerostand or your identity provider's MFA) and per-target step-up before a brokered session; phishing-resistant methods through your identity provider. |
NIS2 Directive and implementing regulation
Directive (EU) 2022/2555, Article 21(2), and Commission Implementing Regulation (EU) 2024/2690, Annex point 11.3, privileged accounts and system administration accounts. The Directive addresses Member States; entities' obligations come from national transposition. The Implementing Regulation's Annex applies to the digital-infrastructure and digital-provider entities it lists (for example cloud, data-centre, managed and managed security service providers).
Official source: Directive (EU) 2022/2555 ↗ Official source: CIR (EU) 2024/2690 ↗| Control | What it asks | How Zerostand supports it |
|---|---|---|
| Directive Art. 21(2)(i) | Human resources security, access control policies and asset management. | Access control policy as code, enforced for people and workloads; discovery and safes as the inventory of privileged accounts; SCIM provisioning from your identity provider. |
| Directive Art. 21(2)(j) | Multi-factor or continuous authentication, and secured communications and emergency communication systems, where appropriate. | The authentication half only: multi-factor authentication through TOTP or your identity provider, with step-up per target. Zerostand does not provide secured communications systems. |
| CIR Annex 11.3.2(a) | Strong identification, authentication (such as multi-factor authentication) and authorisation procedures for privileged and system administration accounts. | Single sign-on through your identity provider, TOTP MFA and per-target step-up before a privileged connection; policy as code for authorisation. |
| CIR Annex 11.3.2(b)–(c) | Accounts used exclusively for system administration, with administration privileges individualised and restricted to the highest extent possible. | Named people reach targets through Zerostand; shared administrator accounts are vaulted, checked out by one person and, where you set it, rotated on check-in. |
| CIR Annex 11.3.3 | Privileged and administration access rights reviewed at planned intervals, adjusted after organisational changes, with results documented. | Recertification campaigns with exportable evidence, an entitlements report and posture findings for stale or over-privileged accounts. |
Financial regulators in Asia-Pacific
Bank Negara Malaysia, the Monetary Authority of Singapore, the Reserve Bank of India and APRA. Each section names the instrument and edition it cites.
Risk Management in Technology (RMiT)
Policy Document on Risk Management in Technology (BNM/RH/PD 028-98), issued 25 September 2026, in effect from 28 November 2025. Paragraphs S 10.53 to S 10.57, access control.
Official source: bnm.gov.my (PDF) ↗| Paragraph | What it asks | How Zerostand supports it |
|---|---|---|
| S 10.54(c) | Time-bound access that restricts access to a specific period based on the nature of the work. | Every grant is a lease with an expiry: access requests, one-off scheduled windows, short-lived SSH certificates and database logins that stop working when the window ends. |
| S 10.54(e) | Criteria for the activities that require dual authorisation control. | M-of-N and sequential approval chains per safe. Emergency access is limited to pre-listed people, capped in time, needs a reason, asks for step-up MFA (required of everyone when you turn that on), and raises its own audit event; a sealed offline export is encrypted to keys your security team holds. |
| S 10.54(f)(iii) | Each online credential uniquely linked to a single user, for clear accountability in access to confidential IT assets. | People sign in through your identity provider. Shared accounts are checked out by one person at a time and, where you turn it on for the safe, rotated on check-in; every session and reveal is tied to a named person. |
| S 10.55 | MFA that can defend against social engineering attacks for user access to critical systems. | TOTP plus per-target step-up MFA in Zerostand. Phishing-resistant methods come from your identity provider over OIDC single sign-on; TOTP on its own is not phishing-resistant. |
| S 10.56 | A user access matrix of access rights, roles and approving authorities, periodically reviewed and updated. | Recertification campaigns with evidence export, an entitlements report and an access graph that shows who can reach what. |
| S 10.57(c) | User activity in critical systems logged; logs kept for at least three years and regularly reviewed. | A hash-chained, tamper-evident audit log that Zerostand never prunes, forwarded to your SIEM by webhook or syslog. Keep it, and your SIEM copy, for at least three years. |
Technology Risk Management Guidelines
January 2021 edition, section 9: user access, privileged access and remote access management. The Guidelines set supervisory expectations ("should"), not legal requirements.
Official source: mas.gov.sg ↗| Paragraph | What it asks | How Zerostand supports it |
|---|---|---|
| 9.1.5 | Multi-factor authentication for users with access to sensitive system functions. | Per-target step-up MFA before a privileged connection, on top of single sign-on through your identity provider. |
| 9.1.6 | Periodic review of access rights, including dormant accounts. | Recertification campaigns with evidence export; posture findings for orphaned, stale and over-privileged accounts. |
| 9.1.8 | Service providers with access to the FI's information assets subject to the same monitoring and access restrictions as its own staff. | Third parties use the same requests, approvals, time-boxed access and recorded sessions as staff. Zerostand has no separate vendor self-service onboarding; your team invites them. |
| 9.2.1 | Privileged access only on a need-to-use basis, logged and reviewed. | Access requests with approval chains and expiry; every grant, session and reveal in the audit log; recertification of what remains. |
| 9.2.2 | A process to manage and monitor the use of system and service accounts for suspicious or unauthorised activity. | Discovery of accounts on servers and databases, safes with rotate, verify and reconcile, workload attestation in place of stored passwords, and dynamic credentials for services. |
| 9.3.1 | Encrypted remote connections and strong authentication, such as multi-factor authentication, for users performing remote access. | MFA before brokered SSH, RDP, database and web sessions where you require it: TOTP in Zerostand or your identity provider's MFA, plus step-up per target; TLS by default on Zerostand's listeners and gateways. |
Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026
The Commercial Banks Directions, issued 31 July 2026. Paragraphs 95 and 104 to 111: audit trails, user access control and privileged access. Equivalent provisions apply to other regulated entities under their own 2026 Directions, with different paragraph numbers.
Official source: rbi.org.in ↗| Paragraph | What it asks | How Zerostand supports it |
|---|---|---|
| Para 95 | Audit trails detailed enough to support audits, serve as forensic evidence and assist dispute resolution, including non-repudiation. | A hash-chained, tamper-evident audit log with the time on every event and the actor on every event a person or workload performs, and the reason and ticket wherever a request carries them, forwarded to your SIEM. |
| Para 104 | Access to information assets only where a valid business need exists. | Access requests with a reason and, where you require it, an open ServiceNow or Jira ticket checked live before the grant. |
| Para 105 | Personnel with elevated access closely supervised, with all their system activity logged and periodically reviewed. | Privileged sessions recorded and replayable, SSH watched live, any session terminated; SQL statements logged for PostgreSQL and MySQL sessions through the gateway; recertification of what remains. |
| Para 110 | Multi-factor authentication, mandatory for privileged users of critical information systems and for critical activities. | TOTP MFA and per-target step-up on top of single sign-on through your identity provider. |
| Para 111 | Systems and controls, for example centralised, to allow, manage, log and monitor privileged, superuser and administrative access to critical systems. | One console to request, approve, broker, record and audit privileged access to servers, databases, Kubernetes and web consoles, with the audit log forwarded to your SIEM. |
Letter on common cyber resilience weaknesses
Privileged access management observations from APRA's letter of 15 August 2024 to all APRA-regulated entities, which refers entities to CPS 234 and the guidance in Prudential Practice Guide CPG 234, and Zerostand capabilities that can support your remediation.
Official source: apra.gov.au ↗| APRA observation | What APRA observed | How Zerostand supports it |
|---|---|---|
| Inventory | "Lack of a complete and accurate inventory of all privileged accounts, including both user and system accounts." | Network and account discovery across servers and databases; safes as the inventory of record; posture findings for orphaned and unmanaged accounts. |
| Need and duration | "Privileged access to information assets is not always approved and granted based on a valid business need and for a specified time." | Every grant expires: access requests with a reason and windows, short-lived certificates and database logins, exclusive checkout, with rotation on check-in where you turn it on. |
| Credential strength and storage | "Privileged access credentials may not always be strong and securely stored in approved solutions." | Safes encrypted at rest under a key-encryption key you hold (passphrase or HashiCorp Vault Transit), passwords generated to a per-platform policy, scheduled rotation and verification, and an audit record of every reveal. |
About these mappings (as at 14 October 2026). This page is general information about how Zerostand features relate to the published frameworks named on it. It is not legal, regulatory or compliance advice, and it is not a certification, attestation, audit or assessment of Zerostand or of any customer. Zerostand is not affiliated with, and these mappings have not been reviewed, approved or endorsed by, any body named on this page, including Bank Negara Malaysia, the Monetary Authority of Singapore, the Reserve Bank of India, the Australian Prudential Regulation Authority, the European Commission and the European Supervisory Authorities, the PCI Security Standards Council, ISO and IEC, the AICPA, NIST, or the U.S. Department of Health and Human Services. "What it asks" is our short paraphrase or, where marked, the control title only; the official text of each framework, in the edition named, is the authority and prevails over anything on this page. Frameworks change, and we update this page periodically, not continuously. Using Zerostand does not by itself make any organisation compliant with any framework: whether a control is met depends on how you configure, operate and govern your environment and on your other controls, and remains your responsibility and your auditor's or regulator's judgement. Framework names are used to identify the frameworks; they may be trademarks of their owners.