PG Bank makes sensitive data movement visible with Cyberhaven DLP
How Alexa Cybersecurity helped a Vietnamese bank establish an operational data protection program across endpoints, cloud collaboration and generative AI workflows.
- Endpoint coverage · figure withheld
- XX%
- Sensitive datasets · count withheld
- XX
- Cloud integrations · count withheld
- XX
- Risk events · volume withheld
- XXXX
Sensitive operational figures and calendar dates are intentionally masked for customer confidentiality. X placeholders do not indicate the magnitude or number of digits in the original values. Detected events are not a count of breaches prevented.
Implementation Timeline
Approximately 30 days
An estimated implementation period covering preparation, deployment, policy configuration, cloud integration and initial operational handover. This approximate duration is based on the delivery team’s recollection, not a verified start-to-finish schedule in the implementation report. Exact calendar dates remain confidential. Ongoing tuning and follow-up remediation continued beyond the initial implementation.
Protecting sensitive data without disconnecting the business
For a bank, sensitive data is not confined to a single application. It moves through documents, spreadsheets, email conversations, collaboration platforms and everyday employee workflows. A useful data protection program must understand that movement while allowing legitimate banking activity to continue.
PG Bank, a bank in Vietnam, engaged Alexa Cybersecurity to implement Cyberhaven Data Loss Prevention. The engagement combined endpoint deployment, sensitive data classification, policy configuration, cloud integration and operational tuning. The objective was to turn previously difficult-to-observe data movement into an operational capability that the bank could monitor, investigate and progressively govern.
The implementation report describes a successfully established DLP operation across the deployed estate. An initial monitoring period provided a practical baseline for understanding how employees handled sensitive information and where additional guidance or stronger controls were needed. Reporting dates and deployment milestones are withheld for confidentiality.
From a deployment plan to an operating capability
The engagement covered an agreed workstation estate, with scope and installation counts withheld in this public account. Alexa prepared standardized installation packages and scripts, automated deployment through Group Policy and supplied installation guidance for the bank’s operations team. Cyberhaven sensors established monitoring across the deployed estate, with the exact coverage percentage kept confidential.
Coverage was treated as a measurable delivery outcome, not a claim of universal protection. Remaining endpoints required compatibility remediation or follow-up installation. These items were retained in the operational improvement plan rather than excluded from the denominator.
The delivery sequence moved from preparation and packaging to classification, policies and dashboards, cloud integration, and ongoing refinement. This gave the bank a structured path from technical installation to day-to-day ownership. Successful delivery therefore meant more than placing an agent on a device. It meant making the resulting signals understandable and actionable for the people responsible for protecting data.
A shared language for sensitive banking information
DLP becomes useful when its definition of sensitive information reflects the organization it protects. Alexa worked with PG Bank’s risk management function to agree the classification approach and translate approved requirements into a set of sensitive data datasets. The number of configured datasets is withheld.
The team refined the pattern-based detection configuration and handed over the classification documentation. Policies were then mapped to the datasets and their risk levels. This connected technical detection to business priorities rather than treating every document or transfer as equally sensitive.
For security and risk teams, the value of this work was consistency. A common classification foundation made it possible to group observations, assess their relative importance and explain why particular handling activities warranted attention. The bank could build its response process around an agreed data model instead of relying solely on isolated alerts.
Connecting endpoint visibility with cloud collaboration
Cloud collaboration integrations extended the program into the environment where employees create, exchange and reuse business information. The specific service inventory and integration count are withheld in this public account.
Evidence capture was configured for higher-severity policy events, with supporting storage established for investigation material. This was intended to give analysts context when reviewing an alert, including the relevant content and activity, rather than requiring them to interpret an event name in isolation.
Configuration and operational readiness were tracked separately. The report retained vendor follow-up for aspects of evidence display and browser behavior. That distinction matters in a real deployment. Enabling a feature is not the same as confirming that every investigation workflow is fully resolved, and the operating plan reflected that.
Making everyday data movement visible
The monitoring approach addressed data movement through everyday digital workflows, including web activity, email and generative AI. The exact monitoring scope is withheld. These observations showed why a modern banking DLP program must look beyond traditional email attachments. Data can leave a managed workflow through an upload, a web-based utility or a simple copy-and-paste action.
Website activity highlighted the importance of reviewing everyday productivity services and external file-processing workflows. Email monitoring provided a basis for distinguishing legitimate collaboration from activity requiring further review. Generative AI monitoring added visibility into a newer pattern, where employees may submit business content to an external assistant while trying to complete an ordinary task.
The report’s closing summary records risk events detected and classified during the initial monitoring period. Event volumes are withheld. These observations should not be interpreted as prevented breaches, confirmed malicious actions or a count of unique affected records. They provided a baseline for investigation, policy tuning and awareness efforts, rather than a standalone measure of security improvement.
This public case study deliberately excludes user identities, destination-specific findings and incident evidence. The important lesson is the operating capability: the bank gained a way to identify data-handling patterns across established collaboration tools and emerging AI workflows, then decide which actions required intervention.
Introducing controls with business context
Warning policies were activated as part of the phased rollout, with the activation date withheld. Under this approach, users received a warning when an activity matched the configured policy conditions. It created an opportunity to address risky behavior and refine policy decisions while the team assessed operational impact.
Warning mode should not be confused with automatic blocking. At the reporting milestone, stronger blocking for selected critical data categories remained a future assessment item. The implementation established visibility and user-facing intervention; it did not claim that every sensitive transfer was prevented.
Alexa and the bank also reviewed false positives and legitimate business exceptions. The report states that all implemented exceptions followed customer approval. This maintained a distinction between an authorized business need and an informal bypass, while preserving the bank’s authority over the final policy decision.
Operational tuning was part of delivery, not an afterthought. Browser-specific observations were escalated to the vendor, user guidance was provided where appropriate and policy refinements were reviewed against real activity. The goal was a program that employees and analysts could work with, rather than an unmanageable stream of undifferentiated alerts.
A measurable foundation for continued improvement
The engagement established a documented foundation of endpoint monitoring, approved sensitive data classifications, cloud integrations and visibility into data movement. The implementation report supports these delivery and visibility outcomes. Deployment quantities, coverage rates and event totals remain confidential.
For PG Bank, the change was from limited visibility into sensitive data movement to a structured process for observing, classifying and reviewing it. Security and risk teams could work from a shared baseline, users could receive direct policy warnings and business exceptions could be handled through an approval process.
The next stage identified in the report included completing remaining endpoint work, following up vendor issues, reviewing exceptions regularly and assessing stronger enforcement for critical datasets. Monthly reporting, employee awareness and a controlled approach to generative AI were also recommended. These were planned improvements, not additional completed outcomes.
The broader lesson is that effective DLP combines technology with implementation discipline. Endpoint coverage, classification quality, cloud context, user guidance and accountable policy decisions reinforce one another. At PG Bank, Alexa brought these elements together into an operating data protection program with a clear baseline and a defined path for further maturity.
About this case study
Based on the customer-provided Cyberhaven DLP implementation summary for PG Bank. Reporting dates, deployment quantities, coverage rates and event totals are withheld, alongside personal identifiers, internal destinations, detailed exception rules and investigation evidence. It does not assert regulatory certification, complete endpoint coverage or universal blocking.



