A practical data-layer security review for Bangladesh BFSI

Try choosing one production database and asking for its last access review, a recent activity alert, and the record of a successful restore. Can the team find all three? Do the records cover the same system and period?

That is a useful starting point for a data-layer review. It brings security, database operations, and infrastructure teams into the same discussion, with evidence they can inspect together.

The framework below is our proposed workshop method for financial-sector teams in Bangladesh. It is not a survey of institutions, a regulatory scoring system, or a compliance assessment. Its purpose is to turn a broad security discussion into a short, owned list of improvements.

Choose a scope before assigning scores

Start with a service people can name, such as an internal reporting application, and list the databases and infrastructure it depends on. Include the identity system, backup storage, and administrative access paths. Agree which period the review covers.

A narrow review with complete evidence is more useful than an estate-wide score based on assumptions. You can extend the scope once the method is working.

Review five areas

1. Access governance

List the application, human, and emergency accounts that can reach production data. For a sample of privileged access, connect the permission to an owner, an approval, and a recorded action. Check what happens when the permission is revoked.

Useful evidence: an access inventory, a completed review, and a traceable privileged session. A policy document alone will not show whether an old account still works.

2. Audit integrity

Check which database events are collected, where they are stored, and who can change or delete them. Look for collection gaps as well as signs of alteration. A tamper-evident chain can help detect changes, but its value depends on protected verification records and a clear threat model.

Useful evidence: a sample event traced from source to retained record, collection-health history, and an integrity-check result. A valid chain does not prove that every relevant event was collected in the first place.

3. Sensitive-data discovery

Choose a known sensitive field and see whether it appears in the inventory. Then ask how a new table would be discovered and classified. Include copies used for reporting or testing in the scope where appropriate.

Useful evidence: a dated inventory, a classification review, and a record of how new data is added. An automated label still needs a way to resolve mistakes.

4. Monitoring and response

Trace an alert through to the person expected to handle it. Does the alert explain what happened? Can that person distinguish a suspicious read from an approved batch job? Check what the team sees when a collector stops sending events.

Useful evidence: a controlled test event, the resulting alert, and the recorded response. Rules and behavioural baselines can both contribute; neither proves that all misuse will be detected.

5. Recovery and data location

Review a restore of representative data, including the credentials and keys needed to recover it. Record how long it took and what the validation covered. Map where primary data, backups, logs, and keys are stored, together with the parties that can access them.

Useful evidence: a restore report, an inventory of storage locations, and tested recovery dependencies. Hosting a database locally does not establish the location of every copy.

Use the score to describe evidence, not declare compliance

For each area, record the highest level the evidence supports across the agreed scope:

Level 0: unknown or informal. Ownership or operation cannot be established reliably.
Level 1: documented. The team has agreed the control and assigned responsibility.
Level 2: operating. Evidence shows the control working in the systems reviewed.
Level 3: repeatedly checked. Dated checks cover the review period, and gaps or failures have an owner and follow-up.

These are our working definitions. They do not require a particular product or one technical implementation. Avoid averaging them into a reassuring total: a strong monitoring score cannot compensate for an untested recovery path.

Turn one finding into an action

For example, a team might find that backups run nightly but nobody can produce a recent restore report. Record the gap precisely: which service, which backup path, and which missing evidence. Assign a restore exercise, an owner, a target date, and an acceptance check.

This is an illustrative finding, not a result from a customer assessment. The point is the shape of the action. A task such as restore the reporting database to an isolated target and validate it is easier to finish than improve recovery maturity.

Repeat the review after the action is complete. Keep the failed checks as well as the successful ones; they explain how the control changed over time.

Where our products can contribute

Vyrell contributes database activity collection, sensitive-data discovery, statistical behavioural analysis, and tamper-evident audit records. It supports investigation of access; monitoring should not be mistaken for preventive access enforcement.

Nothi provides database lifecycle and engine-specific recovery operations. Moncho provides Kubernetes operations and evidence mapped to control references. These mappings are aids to review, not certifications of the tenant’s environment. Dorbar brings meeting infrastructure and its records into the same discussion about location and access.

Our product overview sets out each product’s scope and deployment limits. A complete assessment still needs organizational controls, operational evidence, and a review of the requirements that apply to the institution.

Read the requirements alongside the worksheet

The Bangladesh Bank ICT Security Guideline v4.0 is a reference for the database and ICT controls discussed here. Confirm applicable circulars and subsequent requirements with the institution’s compliance team; this worksheet does not establish the current regulatory baseline.

ISO/IEC 27001 frames information security through a risk-based management system. CIS Control 11 provides a separate reference for recovery practices and testing. Use these sources in their own scope, rather than treating this five-area worksheet as a substitute for any of them.