Access Control Policy

This policy defines how Tanqory controls access to systems, applications, data, and facilities to protect confidentiality, integrity, and availability. It aligns with global standards and regulations (ISO/IEC 27001/27002/27017/27018/27701, SOC 2, PCI DSS, CIS Controls, NIST SP 800-53/171, GDPR/UK GDPR, PDPA, CCPA/CPRA) and applies to all employees, contractors, partners, vendors, and external providers who access Tanqory resources. Contractual terms or customer agreements with stricter requirements prevail.

---

1) Purpose, scope, and principles

Purpose: Establish consistent, auditable controls over identity, authentication, authorization, and monitoring to minimize risk of unauthorized access or misuse.
Scope: All environments (production, staging, development, test, back-office), cloud platforms (IaaS/PaaS/SaaS), endpoints, network devices, CI/CD systems, data stores, support tools, physical offices, and third-party hosted services that process Tanqory or customer data.
Principles: Least Privilege, Need-to-Know, Separation of Duties, Zero Trust (continuous verification, no implicit trust by network location), Layered Security, Secure by Default, Privacy by Design, Accountability, and Auditability.

2) Governance, ownership, and accountability

• Policy owner: CISO (or delegate) is accountable for this policy, periodic review, and exceptions.
• Data owners/system owners: Define access needs, approve grants, and ensure periodic certification.
• Managers: Validate role appropriateness for their team members and trigger deprovisioning on role change/exit.
• Security/IT operations: Enforce technical controls, run identity platforms, monitor access, and maintain logs.
• Audit/compliance: Perform control testing and evidence collection for SOC 2/ISO 27001/PCI DSS and customer audits.
• Users: Follow this policy, protect credentials, report anomalies, and complete required training.

3) Identity and account lifecycle

• Uniqueness: Every user has a unique identity; shared accounts are prohibited except tightly-governed service/break-glass accounts.
• Onboarding: Accounts provisioned via ticket/workflow with approvals from Manager and System/Data Owner for sensitive systems. HR events drive joiner/mover/leaver flows.
• Changes: Role changes trigger prompt access review and adjustment; temporary access has defined expiry.
• Offboarding: Immediate disable/revoke upon termination or role change; checklist covers SSO, VPN/ZTNA, cloud consoles, admin tools, repos, API keys, mail, and physical access.
• Dormant accounts: Disable or re-certify accounts idle >30 days (privileged) or >60 days (standard) unless documented business need.
• Naming and ownership: Service accounts map to an owner/team, purpose, and expiry; no personal email aliases for shared services.

4) Authentication and MFA

• SSO first: All eligible applications must integrate with centralized identity (SAML/OIDC) so accounts, MFA, and deprovisioning are enforced consistently; exceptions for non-SSO systems are documented with compensating controls and periodic review. Local accounts (e.g., appliance defaults) are disabled or changed, managed in vault, and monitored.
• MFA required: MFA is enforced for every user; privileged and production access require phishing-resistant factors (hardware security keys/FIDO2) where possible. Step-up MFA is triggered for high-risk events (e.g., admin actions, sensitive data downloads, new device/geo/login anomalies).
• Password policy: Strong passwords follow NIST 800-63B/CIS (minimum length, complexity or passphrases, blocklists against breached/common passwords). Rotation is risk-based (after compromise or high-risk indicators), not arbitrary. Passwords never stored in cleartext; hashing follows modern standards.
• Session security: High-risk systems use short session lifetimes, idle timeouts, and forced re-authentication for sensitive actions (e.g., role changes, API key creation, bulk exports). Device posture (MDM/EDR) and geolocation/IP reputation feed ABAC for allow/deny/step-up decisions. Session tokens are short-lived, tied to device, and invalidated on logout or compromise.
• Recovery: Account recovery uses MFA-backed workflows and verified channels; helpdesk performs identity proofing with approved methods before reset. Break-glass accounts stay offline in vault with dual control, single-use credentials rotated immediately post-use; every access is fully logged and reviewed.
• Credential hygiene: No credential sharing; API keys scoped and short-lived; SSH keys use strong algorithms and are rotated; default/vendor credentials are changed on first use; secret scanning in repos and CI prevents accidental exposure.

5) Authorization, RBAC, ABAC, and SoD

• RBAC: Standard roles (e.g., Platform Admin, Security Admin, Database Admin, SRE, Developer, Support, Finance/HR, Sales/CS) are defined with least privilege per environment (dev/test/stage/prod segregated). Role descriptions include allowed systems, data classifications, and prohibitions; promotion to higher-privilege roles requires approvals and training.
• ABAC: Contextual rules (time/IP/geo/device posture/risk/data sensitivity) dynamically tighten, deny, or require step-up MFA. Examples: block downloads of Restricted data from untrusted IPs, require compliant devices for admin consoles, restrict after-hours prod changes, and deny access from embargoed geos. ABAC policies are versioned, tested in lower environments, and monitored for false positives.
• Separation of Duties: Conflicting duties are split (e.g., code author cannot approve own deploy; payroll entry vs. approval; security monitoring vs. log administration; identity admin vs. access reviewer). SoD matrices define conflicts; exceptions are rare, documented, time-bound, and reviewed.
• Privileged Access Management (PAM): Admin rights are JIT, time-bound, and task-scoped via PAM tooling; elevation requires approval (Manager + System/Data Owner + Security for high risk) and is fully logged/recorded where feasible. Standing admin is avoided; if granted, it has an expiry and more frequent review. Shared/root credentials are vaulted with dual control and checkout logs.
• Periodic review: Roles, groups, ABAC rules, and elevated accesses are reviewed at least quarterly (monthly for production/privileged). Access that is unused or unjustified is removed; evidence of certification is retained for audits. Recertifications include service accounts and third-party/vendor accounts.
• Change control: Updates to roles, SoD matrices, and ABAC rules follow change management (testing, approvals, rollback); emergency changes receive retroactive approval and review.

6) Access requests, approvals, and recertification

• Requests: All requests go through ticketing/IGA with a clear business justification, required scope (systems, roles, data classifications), and time limit. Requests must state whether personal data or Restricted data is involved. Emergency/break-glass requests are flagged and reviewed post-use.
• Approvals: Manager confirms role fit; System/Data Owner approves access to their system/data; Security reviews privileged, production, or high-risk access. Sensitive data or production write/admin requires multi-party approval. Evidence (ticket IDs, approvers, timestamps) is retained.
• Recertification: Production/finance access is reviewed quarterly; domain/tenant/cloud admins monthly; service accounts at least semi-annually. Reviews validate necessity, least privilege, and last use. Unused or unjustified access is removed. Recertification evidence is collected for SOC 2/ISO/PCI and customer audits.
• Exception handling: Temporary deviations (e.g., legacy apps without SSO/MFA, urgent access) require documented risk acceptance by Security and the Data/System Owner, a defined expiry, and compensating controls (short-term accounts, tighter logging, JIT elevation). Exceptions are tracked and reviewed until closed.

7) Network, remote access, and sessions

• Zero Trust Network Access (ZTNA)/VPN: All production and internal admin access goes through ZTNA/VPN with MFA and device posture checks. Access is based on identity and device trust, not network location.
• Segmentation: Production is isolated from non-production; management planes are separated from data planes. Firewalls/security groups restrict East-West and North-South traffic to only what is necessary. Admin consoles, bastions, and databases are further isolated with allowlists and ZTNA.
• Ingress/Egress controls: Admin consoles and databases are reachable only from approved IPs or via ZTNA; outbound filtering limits sensitive networks from reaching the internet except for approved endpoints (e.g., patch repos). DDoS/WAF and rate limiting protect exposed endpoints.
• Session control: Idle timeouts and absolute lifetimes are enforced for high-risk systems; re-authentication is required for sensitive operations (role changes, key creation, bulk exports). Anti-hijack measures include secure cookies, token binding where supported, and anomaly detection.
• Remote work: Privileged access is allowed only from managed/compliant devices; public/shared devices are forbidden for privileged actions. Wi‑Fi in public places must use VPN/ZTNA; shoulder surfing and eavesdropping risks are mitigated by screen privacy and user awareness.
• Monitoring: Network access logs (VPN/ZTNA/firewall) flow to SIEM; alerts on impossible travel, unusual bandwidth, or new locations for admin accounts trigger investigation.

8) Endpoint and device access

• MDM/EDR: Corporate and approved BYOD (where permitted) must enroll in MDM, enforce full-disk encryption, screen lock, patching, EDR, and device compliance checks. Non-compliant devices are blocked from sensitive resources.
• Configuration baseline: CIS or equivalent hardened baselines apply to OS, browsers, and security tooling. USB/removable media are restricted or read-only; autorun is disabled. Mobile devices require PIN/biometric lock and encryption.
• App control: Only authorized software is allowed; high-risk or unapproved tools (e.g., unauthorized remote access, torrent clients) are blocked. Local admin rights on endpoints are rare, time-bound, and reviewed; elevation uses JIT where possible.
• Lost/stolen devices: Report immediately; remote lock/wipe is executed; associated credentials/tokens are revoked or rotated. Incident response assesses data exposure; users complete additional training if required.
• Data handling on endpoints: No storage of production data or secrets locally unless explicitly approved and encrypted; clipboard and print restrictions may apply for Restricted data; caching of PII is minimized.

9) Data access, classification, and handling

• Classification: Public, Internal, Confidential, Restricted, mapped to handling rules.
• Need-to-know: Access to Confidential/Restricted data requires explicit approval; storage and transmission must be encrypted (TLS 1.2+; AES-256 at rest).
• Data minimization: Only collect/store what is necessary; test/support use masked or pseudonymized data.
• DLP: Apply DLP for email, file sharing, and endpoints to prevent unauthorized exfiltration.
• Exports/downloads: Controlled for Restricted data; may require encryption, watermarks, and approval.
• Data subject rights: Logging supports fulfillment of GDPR/PDPA access/erasure/portability requests.

10) Application, CI/CD, and database access

• Source control: SSO+MFA; least-privilege repo access; protected branches; code owners; mandatory reviews; no secrets in code.
• CI/CD: Access scoped by role; pipeline credentials stored in vault; approvals for production deploys; artifact integrity checks.
• Database/storage: Admin access limited to DBAs/SRE with JIT; read/write separated from admin; queries against production PII restricted and logged; replicas/snapshots protected; copy to lower environments requires masking.
• Support tooling: Scoped support roles; just-enough access; customer access requires authorization and case linkage; session recording where feasible.

11) Cloud and platform access

• Cloud IAM: Use federated access with SSO/MFA; minimize local IAM users; employ roles with least privilege, SCPs/guardrails, and resource tagging for ownership and data classification.
• Key management: Cloud KMS with strict role separation (key admins vs. crypto users); rotation per key policy; customer-managed keys supported where contracted.
• Console/API access: Privileged actions require MFA; API keys are scoped, short-lived, and stored in vaults; access logs sent to SIEM.
• Workload identities: Use managed identities/service principals for services; avoid long-lived keys.
• Change control: Infrastructure changes go through change management with approvals and logging.

12) Secrets, keys, and credentials management

• Vault-first: Secrets stored in a centralized secrets manager; access controlled by RBAC/ABAC, logged, and rotated automatically where possible.
• Separation: No secrets in code, config repos, or tickets; scanning for secrets enforced in CI.
• Rotation: Follow rotation schedules (see Appendix B); rotate after suspected compromise or emergency use.
• Encryption keys: KMS/HSM where required (e.g., PCI DSS); split duties between key custody and usage; backups of keys handled securely.

13) Logging, monitoring, and detection

• Coverage: Log authentication, authorization changes, privilege elevation, data access (where feasible), admin actions, and configuration changes across SSO, IAM, OS, DB, network, and apps.
• Centralization: Forward logs to SIEM; time-synced (NTP); protect integrity and confidentiality of logs.
• Detection: Alerts for anomalous access (impossible travel, brute force, excessive data access, privilege changes, failed MFA); playbooks define response steps.
• Retention: Retain per legal/contractual requirements (e.g., PCI DSS, tax/audit), with access controls on logs.

14) Third-party, vendor, and customer access

• Due diligence: Security/privacy assessment before granting access; DPA/SCC or other transfer mechanisms for personal data; minimum necessary scope and time.
• Onboarding: Named accounts, MFA, SSO where supported; NDA and acceptable use.
• Monitoring and review: Quarterly reviews for vendor access; immediate revocation at contract end or task completion.
• Customer access: If customers receive portal/API access, controls are enforced per this policy and contract (e.g., tenant isolation, rate limits, logging).

15) Physical and environmental access

• Facilities: Badge-controlled entry; visitor logs and escorts; CCTV where allowed by law.
• Data centers: Use vetted providers with ISO 27001/SOC 2; access limited to authorized staff/escorted; separate cages/rooms where applicable.
• Media: Secure disposal/destruction (e.g., shredding, degauss, NIST 800-88 methods); chain of custody for removable media.
• Equipment: Servers and networking gear in secured areas; no production data on personal devices.

16) Remote support, shared screens, and recordings

• Support sessions use approved tools with session logging/recording where feasible; customer consent obtained per law.
• Screen sharing must avoid exposing secrets; clipboard redirection limited; recordings stored securely with retention limits.

17) Business continuity and disaster recovery alignment

• Access paths to critical systems documented in BCP/DR plans; break-glass procedures available offline for emergencies with post-use review and rotation.
• Periodic BCP/DR tests include validation of emergency access and recovery of identity systems (SSO, MFA, directory).
• Backups of identity/authorization config are encrypted, access-controlled, and tested.

18) Incident response integration

• Suspected unauthorized access triggers the Incident Response Plan: contain (disable accounts/tokens), investigate (log review, forensics), notify stakeholders/customers/regulators where required, and eradicate (rotate credentials, patch).
• For personal data incidents, follow breach notification timelines under GDPR/UK GDPR/PDPA/CCPA and contractual SLAs.
• Post-incident reviews drive control improvements and awareness training.
• Access-related tabletop scenarios (e.g., SSO outage, credential stuffing, insider abuse) are run periodically to validate procedures and tooling readiness.

19) Change management

• Access-related changes (role definitions, ABAC rules, PAM configurations, SSO integrations) follow change control with approvals, risk assessment, testing, rollback plans, and logging.
• Emergency changes are documented with retroactive approval and review.

20) Metrics and continuous improvement

• Track: time to provision/deprovision, percentage of MFA-enabled accounts, number of privileged users, recertification completion, failed/denied authentications, anomalous access alerts, break-glass usage, and audit findings.
• Review metrics monthly; corrective actions assigned with due dates.
• Periodic internal audits and external assessments (ISO/SOC/PCI) validate control effectiveness.

21) Training and awareness

• Mandatory security and access control training at onboarding and annually; role-based modules for admins, developers, and support.
• Phishing/MFA hygiene awareness; acceptable use of customer data; handling of secrets; incident reporting.
• Training completion is required before granting privileged access.

22) Exceptions and risk acceptance

• Exceptions documented with scope, reason, compensating controls, owner, and expiry; approved by Security and the relevant Data/System Owner.
• Periodic review ensures exceptions do not become permanent without re-approval.

23) Data subject rights and privacy considerations

• Access to personal data is limited and logged to support audit trails for access/erasure/rectification/portability requests.
• Role design minimizes exposure to PII; pseudonymization and masking used in non-production.
• Cross-border access follows data transfer mechanisms (e.g., SCCs/IDTA/CBPR) and geo-fencing where required by contract or law.

24) Customer-managed keys and tenant isolation (where offered)

• If BYOK/CMK is provided, customers control encryption keys for their data; Tanqory implements strict separation of key admins and data operators, enforces key usage logging, and supports customer key revocation with defined service impacts.
• Tenant isolation is enforced via logical and, where needed, physical controls; access to one tenant’s data by another tenant’s users is prohibited by design.

25) Regulatory and standard mappings (summary)

• ISO/IEC 27001/27002: Annex A controls on access control, cryptography, operations, supplier relationships, and compliance reflected in Sections 1–24.
• SOC 2: CC6 (Logical/Physical), CC7 (System Operations), CC8 (Change Management) covered by authentication, authorization, monitoring, and change controls.
• PCI DSS: Req. 7/8 (Access, ID, Authentication), Req. 10 (Logging), Req. 12 (Security Policy) covered by Sections 3–20.
• GDPR/UK GDPR/PDPA/CCPA: Integrity/confidentiality (Art. 5/32), data minimization, access logs for rights requests, and breach handling covered by Sections 6/9/18/23.
• Additional mappings (HIPAA, FedRAMP, MAS TRM, CSA STAR) can be appended per customer or regulatory needs.

26) Container, serverless, and runtime access

• Kubernetes/containers: Cluster access via SSO/MFA; role-based access (RBAC) enforced in the control plane; separate namespaces per environment/tenant; no direct node SSH except break-glass. Admission controllers enforce image signing, non-root, and minimal capabilities. kubeconfig files are short-lived and distributed via secure channels; audit logging enabled.
• Images and registries: Private registries with scoped credentials; image scanning for vulnerabilities and secrets; signed images (e.g., Sigstore/Cosign) required for production; promotion pipelines enforce approvals.
• Serverless/functions: Deployment via CI/CD with approvals; least-privilege roles for function execution; environment variables stored in vaults; per-function IAM roles; logs streamed to SIEM.
• Runtime security: EDR/behavioral monitoring on containers/functions where supported; alerts for privilege escalation, breakout attempts, or anomalous network flows; policy-as-code (e.g., OPA) to enforce guardrails.

27) Data lifecycle, backups, and restoration access

• Lifecycle controls: Access at each stage (create, use, share, store, archive, destroy) follows classification rules. Retention schedules are enforced; expired data is deleted or anonymized.
• Backups: Encrypted in transit/at rest; access restricted to backup admins with JIT elevation; restores require approval from Data/System Owner and, for production, Security. Backup copies inherit access controls; test restores use masked data when possible.
• Restoration: Restoration to lower environments requires masking/pseudonymization; restoration requests are logged with ticket linkage, scope, and justification.
• Disposal: Media and logical destruction follow NIST 800-88 or equivalent; certificates of destruction retained.
• Legal/contractual retention: Overrides standard retention; access to legally held data is tightly controlled and logged.

28) Identity verification, helpdesk, and customer support access

• Identity proofing: Helpdesk and support must verify identity using approved methods (out-of-band verification, signed requests from verified contacts, or in-product secure channels) before account changes or data access.
• Customer impersonation: If impersonation tools are used, they are scoped, time-bound, logged, and require customer authorization per case. Session recording or read-only modes are used where feasible to reduce risk.
• Password/MFA resets: Performed only after identity verification; resets logged with case ID; temporary codes expire quickly.
• Case linkage: Support access to customer data is tied to ticket/case IDs with business justification; access ends when case closes.

29) Legal hold, eDiscovery, and logging retention

• Legal holds: When issued by Legal, automatic deletion/retention settings are paused for affected data; access is limited to authorized personnel; chain of custody is documented.
• eDiscovery: Requests for data export follow documented procedures with approvals from Legal and Data Owner; exports are encrypted, access-controlled, and logged.
• Log retention: Logs retained per regulatory/tax/audit needs (e.g., PCI DSS, SOX-like requirements) and legal holds; segregation of duties prevents log tampering.
• Privacy: Exports and holds respect data minimization; only relevant data is disclosed; privacy impact is assessed for large or sensitive collections.

30) Customer, auditor, and regulator access and evidence

• Customer audits: Reasonable audit requests under contract are fulfilled via evidence packages, attestation letters, and controlled walkthroughs; direct system access by customers is avoided unless explicitly agreed.
• Third-party assurance: ISO 27001/SOC 2/PCI DSS reports, penetration test summaries, and SIG/CAIQ responses are provided under NDA.
• Regulator inquiries: Handled by Legal/Security; access provided only as required by law; scope is minimized; all disclosures are logged.
• Evidence handling: Evidence for audits uses redaction and least privilege; stored securely with retention limits and access logs.

31) Metrics, KPIs/KRIs, and reporting

• Key KPIs/KRIs: MFA coverage; number of privileged accounts; time to provision/deprovision; percentage of timely recertifications; number of exceptions and their age; anomalous access alerts and mean time to respond; break-glass uses; access-related incidents; secret exposure findings in CI/CD; compliance test pass rates.
• Reporting: Monthly to Security leadership; quarterly to executives and, where relevant, the Board/Risk Committee. Trends drive remediation plans with owners and due dates.
• Continuous improvement: Metrics inform training focus, automation priorities (e.g., JIT/PAM rollout), and policy updates.
• Targets: Defined thresholds (e.g., 100% MFA for workforce, <24 hours deprovisioning, <5% overdue access reviews) are tracked; deviations trigger corrective actions with deadlines.

32) Policy maintenance and review

• Reviewed at least annually or after significant changes in law, standards, architecture, or incidents.
• Proposed changes follow change management; material changes communicated via internal channels and posted at https://legal.tanqory.com/.
• English version controls; if any section is deemed unenforceable, the remainder still applies.
• Versions are tracked with change logs and approval records; superseded versions are archived for audit.
• Feedback from audits, pen tests, incidents, customers, and regulators is triaged and, when applicable, incorporated into updates with documented owners and timelines.

34) Data residency, geofencing, and cross-border access

• Residency/sovereignty: Where contracts or law require (e.g., EU/UK, India payment data, certain APAC/MEA jurisdictions), data is stored and processed in-region; access from out-of-region requires documented approval and technical controls (VPN/ZTNA with geo checks, ABAC rules).
• Cross-border transfers: Follow approved mechanisms (e.g., SCCs/IDTA/CBPR, Transfer Impact Assessments) and least-privilege principles; logging supports demonstration of compliance.
• Geo-fencing: High-risk actions (admin changes, bulk exports) may be restricted to approved geos/IPs; alerts on access from unexpected countries.
• Cloud locality: Resource tagging and account structuring enforce segregation by region/tenant; backups respect locality requirements.

35) High-risk data domains

• Payments/PCI: Access limited to PCI scope assets with stricter controls (network isolation, dual control for key management, quarterly access review, logging per PCI DSS 10, least privilege per Req. 7/8). No storage of CVV; PAN handling only where contractually required with tokenization preferred.
• Healthcare/PHI (if applicable): Additional safeguards per HIPAA/HITECH or local laws; minimum necessary; audit trails for PHI access; BAAs where required.
• Government/regulated data (if applicable): Apply required clearance, citizenship/geo restrictions, and elevated logging/segregation (e.g., ITAR-like requirements) when serving such customers.
• Biometrics/identity docs: Access heavily restricted, encrypted, and logged; retention minimized; deletion on purpose completion; local law consent rules observed.
• Crypto/keys/secrets: Handling only via vault/KMS/HSM; dual control for key operations; no plaintext export; approvals and logs retained.

36) SaaS usage and shadow IT control

• App governance: New SaaS apps vetted for security/privacy; preference for SSO/MFA and enterprise controls; Data Processing Agreements in place where personal data is processed.
• SSO enforcement: Apps must integrate with SSO; standalone credentials are exceptions with documented risk acceptance and compensating controls.
• CASB/SSPM (if used): Monitor for unsanctioned apps and risky configurations; remediate or block shadow IT; educate users on approved tooling.
• Local admin and software installs: Restricted to IT/Security-approved tools; requests for exceptions are time-bound and logged.

37) Testing, drills, and assurance

• Penetration testing and red teaming: At least annually for production; scope includes access pathways, privilege escalation, and lateral movement. Findings tracked to closure.
• Tabletop exercises: Include access control failure scenarios (compromised SSO, stolen device, insider misuse); test break-glass procedures and communication.
• Control testing: Periodic SOX-like or internal controls testing of access provisioning/deprovisioning, recertifications, PAM, and log review.
• Tooling validation: Periodic reviews of SIEM rules, DLP policies, and ABAC configurations to ensure effectiveness and low false positives.
• Lessons learned: Output from tests feeds updates to roles, ABAC rules, training, and automation roadmap.

38) User responsibilities and acceptable use

• Keep credentials, MFA devices, and hardware tokens secure; do not share accounts or credentials.
• Access only data and systems required for your role; avoid curiosity browsing.
• Do not store customer secrets or production data on personal drives or unauthorized clouds; use approved storage and collaboration tools.
• Lock screens when away; avoid shoulder surfing risks; report lost/stolen devices or suspected compromise immediately.
• Do not bypass security controls (VPN/ZTNA/MDM); do not install unapproved remote-access or tunneling software.
• Follow clean desk and clear screen practices in offices; dispose of printed sensitive material securely.
• Report suspicious activity (phishing, anomalous logins, unauthorized requests) to Security without delay.

39) Shared responsibility model and customer controls

• Tanqory operates a shared responsibility model: Tanqory secures the platform and core services; customers configure their tenant (users, roles, API keys, IP allowlists) per their policies.
• Customers are responsible for vetting their users, managing their own access reviews, and protecting their credentials and API keys.
• Tanqory provides tenant-level controls (MFA enforcement, SSO/SAML where available, API scopes, audit logs, webhooks) to support customer governance.
• Documentation clarifies boundaries for each product (e.g., who manages data residency settings, backups visibility, log retention options).
• Where customers request custom controls (e.g., IP whitelisting, dedicated environments, customer-managed keys), these are provided per contract and may carry service limitations if disabled.

40) Access risk assessment and categorization

• Risk tiers: Access types categorized (e.g., Level 1 = standard business apps; Level 2 = internal tools with limited data; Level 3 = production read; Level 4 = production write/admin; Level 5 = security/identity root-level). Controls scale with risk (MFA hardware keys, JIT, session recording, higher review frequency).
• Data sensitivity impact: Access to Restricted/PII/financial/payment data triggers elevated controls (shorter sessions, tighter ABAC, more frequent reviews).
• Change approval: Higher-risk access changes require multi-party approval (Manager + System/Data Owner + Security), with ticket evidence and expiry.
• Periodic reassessment: Risk tiers reviewed annually to align with evolving threats, business changes, and audit findings.

41) Glossary (selected)

RBAC: Role-Based Access Control.
ABAC: Attribute-Based Access Control.
SSO: Single Sign-On.
MFA: Multi-Factor Authentication.
PAM: Privileged Access Management.
DLP: Data Loss Prevention.
SIEM: Security Information and Event Management.
BYOK/CMK: Bring/Customer Your Own Key.
Break-glass account: Emergency account with controlled use.

---

Appendix A: Example RBAC role scoping (illustrative)

• Platform Admin (Prod): JIT elevation only; can manage infrastructure services and deployments; cannot alter billing or HR data.
• Security Admin: SIEM/SOAR, EDR, vulnerability management; cannot deploy app code; no payroll access.
• Database Admin: Admin rights to production databases via bastion/JIT; no code deploy rights.
• Developer (Prod-read): Read-only to logs/metrics; no write to prod; can deploy via CI/CD if approvals met.
• Support (Scoped): Case-linked, time-bound access to customer data; downloads restricted; session recording where feasible.
• Finance/HR: Access to financial/HR systems only; no production system access.
• Sales/CS: CRM and support tools; no production shell/DB access.

Appendix B: Rotation and session cadence (guidance)

• Passwords: strong, non-reused; rotate on suspicion/compromise.
• Privileged passwords/keys: rotate at least every 60 days or after emergency use.
• API keys/service tokens: scoped, short-lived (≤90 days) unless system constraints dictate shorter; rotate on departure of owners.
• KMS keys: per key policy (e.g., annual auto-rotation) or stricter by contract.
• Session tokens: short-lived (e.g., 8–12 hours); idle timeout 15–30 minutes for high-risk systems; lockouts after repeated failures.
• Break-glass: rotate immediately after use; dual control for checkout.

Appendix C: Example approval matrix

Appendix D: Physical access controls (summary)

• Badge with photo ID; least privilege zones; visitor escorts; logs retained.
• Data center provider compliance: ISO 27001/SOC 2; background checks for staff; dual-factor entry where available.
• Environmental protections: power redundancy, fire suppression, climate controls, and CCTV.