How FirstMac Removed Standing Privilege Risk Across AWS, Azure, and On-Prem to Meet ISO 27001 and PCI DSS

FirstMac's privileged access requirements span five distinct scenarios covering different teams, access types, and compliance obligations. Each was addressed under the same Britive architecture rather than with separate tooling per surface. 

Scenario: FirstMac's developer, DevOps, data engineering, and security teams each require elevated AWS access for different purposes: deployments, pipeline management, data environment access, and security investigations. Access needs vary by team and task, and each requires a different scope of permission. 

Before: AWS roles were pre-provisioned and access was controlled through AD group membership. Different teams shared or held overlapping group memberships, making it difficult to enforce least-privilege scoping per team or per task. Sessions persisted beyond the intended access window when group membership was revoked. 

After: Each team checks out a scoped AWS role through the Britive UI or CLI, appropriate to their function. The role is created on AWS at checkout and removed at session end. Scope is enforced at the role level, not the group level, so developers, DevOps engineers, data engineers, and security analysts each operate within the permissions their task requires. 

Why It Matters: Role-scoped, time-bound access per team and task type is a direct PCI DSS least-privilege control requirement. It also reduces the practical impact of a compromised credential since the scope of that credential is bounded to the session and the role checked out. 

Scenario: FirstMac runs workloads across both AWS and Azure. Azure Entra ID serves as the centralized identity provider. Teams needing privileged access to Azure resources required the same JIT governance model applied to AWS, under the same control plane. 

Before: Azure access followed the same AD group membership model as AWS. There was no native integration between the group-based access model and a JIT enforcement layer, so Azure access had the same session persistence and audit reconstruction problems as AWS. 

After: Britive integrates with Azure Entra ID for SSO and governs privileged Azure access under the same policy engine and audit trail as AWS. An engineer requesting elevated Azure access checks out a scoped role, completes the task, and access is removed. The same approval and MFA workflow applies regardless of whether the target is AWS or Azure. 

Why It Matters: A single policy engine across AWS and Azure means one access standard, one audit trail, and one compliance posture for both environments. ISO 27001 and APRA CPS 234 auditors reviewing privileged access controls across the cloud environment see a consistent record rather than two separate systems to correlate. 

Scenario: FirstMac's data and platform teams require privileged access to on-premises and cloud databases including PostgreSQL, Microsoft SQL Server, and MySQL for production support, data operations, and system maintenance. Database credentials are among the most sensitive in the environment and historically among the hardest to govern under a consistent access model. 

Before: Database access relied on shared or persistent credentials managed outside the cloud access model. There was no JIT provisioning for database access, no automated revocation, and no shared audit trail covering database sessions alongside cloud access events. 

After: Britive Access Broker manages database access without standing credentials and without placing a proxy in the session data path. An engineer requests access to a specific database, Britive provisions scoped credentials at the moment of request, and the credentials are revoked when the session ends. The access event is logged in the same audit trail as AWS and Azure access. 

Why It Matters: Persistent database credentials are one of the most common control gaps auditors identify in PCI DSS cardholder data environment reviews. Time-bound, automatically revoked database credentials with a continuous audit trail address that gap directly without requiring changes to existing database infrastructure. 

Scenario: FirstMac's platform and operations teams require SSH access to infrastructure hosts for system administration, configuration management, and incident response. As a regulated financial institution, FirstMac also has a requirement to monitor privileged sessions on sensitive systems, with the ability to retrieve those recordings for forensic investigations, periodic access hygiene reviews, or audit evidence requests. 

Before: SSH access relied on static key pairs and shared credentials with no automated provisioning or revocation. Session recording was not in place. The available approaches in the market treated session recording as a binary capability: record everything or record nothing. Recording everything across a large infrastructure environment generates substantial storage volume and cost, making comprehensive session capture difficult to sustain at scale. 

After: Britive governs SSH access under the same JIT model as cloud and database access, with provisioning at checkout and revocation at session end. Session recording is controlled through Britive policy rather than a global setting, so FirstMac can target recording to specific systems, roles, or access profiles based on sensitivity classification. High-risk sessions on production infrastructure are recorded. Routine access to lower-sensitivity systems is not. Recordings are stored and retrievable directly from the Britive UI, giving security and compliance teams a single location to pull session activity when a forensic investigation requires evidence, when an audit review covers a specific time window, or when periodic hygiene reviews require confirming what actions were taken during elevated sessions. 

Why It Matters: Regulated financial institutions face monitoring requirements that specify which privileged sessions must be recorded, not that all sessions must be recorded. A policy-driven recording model that maps to system sensitivity meets the regulatory obligation without generating indiscriminate storage volume. The ability to retrieve recordings from one UI without coordinating across separate logging or recording systems reduces the time it takes for security teams to produce session evidence when it is needed. 

Scenario: Across all of the above access types, FirstMac needed consistent MFA enforcement and approval workflows that produced auditable records of who approved what, when, and under what justification. ISO 27001 and PCI DSS both require documented evidence of access approval for privileged access events. 

Before: Approval workflows and MFA requirements varied by environment. Some access types had manual approval steps with no automated audit record. Others had no approval workflow at all. Producing consistent access approval evidence across environments required manual report generation before each audit cycle. 

After: Every Britive checkout requires MFA authentication and triggers the configured approval workflow for that access type and environment. Approval records, requester identity, justification, approver identity, timestamp, session duration, and revocation time are all captured automatically and available in a continuous audit trail without manual effort. 

Why It Matters: For ISO 27001 Annex A.9 access control requirements and PCI DSS Requirement 7 (restrict access to system components), documented evidence of access approval for each privileged access event is a mandatory control. Britive generates that evidence as a structural output of every checkout rather than as a reporting task before each audit.