A merchant banker can lose control of a transaction without losing the files themselves. One stale permission, one weak backup, or one vague incident clause can create a bigger problem than the data room ever solved. That is why the right question is not “cloud or on-premise?” It is who controls each critical layer, who can prove it worked, and who carries the risk when the deal moves fast.
This is where a deployment-and-control framework helps. It forces the buyer to map ownership of identities, permissions, encryption keys, logs, backups, incident response, retention, and exit before signing. Below is a practical checklist, comparison points, and a simple operating guide you can use in a demo or procurement review.
What makes this decision different from a normal software choice?
A VDR is not just storage. For regulated deal teams, deployment determines the control boundary. That boundary affects evidence, not just convenience.
For an enterprise VDR, the key question is whether the model leaves the right controls with the right accountable party. SaaS reduces infrastructure work. Customer-managed cloud adds more buyer control. An on-premise VDR gives the most direct infrastructure control, but also shifts more responsibility to the buyer.
1. What data, duties, and risks must the room support?
Start with the transaction, not the vendor. A merchant banker’s room may hold unpublished price-sensitive information, personal data, due diligence records, legal opinions, and board materials.
Check:
- What data classes will live in the room?
- Which items need legal hold or extended retention?
- Which users may see, download, print, or share them?
- What must be destroyed or returned after close?
- What evidence must survive the transaction?
Do not treat encryption alone as proof of compliance. A compliant enterprise VDR depends on configuration, process, and evidence.
2. Where will data, replicas, backups, and support access exist?
Data residency is more than a dashboard label. Ask where the primary data, backups, logs, thumbnails, and support access actually sit.
For a customer-managed cloud, confirm:
- Cloud account ownership
- Storage and backup destinations
- Encryption key custody
- Security log access
- Support access paths
- Region selection for data and replicas
DCirrus publicly states that it uses AWS data centers and offers geographic data-location selection, but the exact region coverage, replica design, and support-access locations still need written confirmation.
3. Which party controls the security boundary?
Make shared responsibility explicit. For every layer, ask who owns it, who operates it, and who can change it.
That includes:
- Physical facilities
- Network and firewalls
- Operating system
- Storage and database
- Application
- Identity provider
- Encryption keys
- Backups
- Audit logs
- User permissions
- Incident response
- Data deletion
This is where an on-premise VDR can look attractive. But it does not remove application risk, insider risk, or recovery risk. It simply moves more of that burden inside the buyer’s environment.
4. How will identities and permissions be controlled?
Least privilege should be the default. The platform should support transaction-specific access, not broad role sprawl.
Test for:
- Unique user accounts
- MFA for admins and external users
- Device approval or registration
- IP restrictions for sensitive roles
- Folder and file-level permissions
- Separate view, download, print, copy, upload, and Q&A rights
- Time-limited invitations
- Maker-checker approval for access changes
- Immediate revocation when a user leaves
SEBI’s cybersecurity framework calls for least privilege, zero-trust thinking, periodic access review, maker-checker controls, and MFA for critical systems. Your VDR should make those controls practical, not aspirational.
5. Can the platform prevent, deter, and prove unauthorized use?
Separate the three jobs.
- Prevention: block download, print, copy, sharing, and unapproved devices
- Deterrence: use dynamic watermarking with user identity, IP, timestamp, and transaction details
- Detection: capture view, download, print, login, permission, invitation, and revocation events
DCirrus publicly describes remote revocation, download and print blocking, dynamic watermarks, and activity logs. Buyers should still test screenshot behavior, mobile behavior, and downloaded-file workflows in the actual environment.
An enterprise VDR should reduce misuse and create evidence. It cannot stop every bad actor from photographing a screen.
6. Are encryption and key-management claims specific enough?
Do not accept “secure” as a complete answer. Ask what exactly is encrypted, how keys are handled, and who can decrypt the data.
Verify:
- Encryption for data at rest, in transit, backups, and logs
- TLS versions
- Key generation, storage, rotation, and revocation
- Customer-managed key availability
- Support-personnel access to plaintext
- Key destruction at termination
DCirrus’s public material states AES-256 encryption and TLS 1.2/1.3, but it does not establish a customer-held key model. That distinction matters.
A customer-managed cloud may offer stronger key and network control, but only if the technical design and contract say so clearly.
7. Will the VDR produce defensible audit evidence?
A dashboard is not enough. The record must be exportable and readable after the deal closes.
Require:
- Unique user identity
- Timestamp with known time source
- IP and device data where collected
- Document, folder, and version identity
- Action type and success or failure status
- Q&A history
- Administrator and support actions
- Searchable export by transaction and time window
- Retention and deletion behavior
SEBI recordkeeping expectations make this non-negotiable. The buyer should be able to preserve both the documents and the surrounding history.
8. How will the platform handle incidents and recovery?
Ask for a transaction-specific incident playbook. It should cover notification timing, log preservation, access revocation, forensic support, and recovery validation.
Also verify:
- Who notifies whom
- What evidence is preserved
- How fast logs can be produced
- Whether restores are tested
- What RPO and RTO are actually supported
Public material says DCirrus uses multi-location backup for disaster recovery, but the exact recovery commitments still need confirmation. That is true for any enterprise VDR buyer, not just this one.
9. Can the firm exit without losing evidence?
Exit is a control, not an afterthought. You need to know what happens to files, metadata, Q&A history, permissions, and logs when the room closes.
Ask whether the export includes:
- Original files and versions
- Folder hierarchy
- Metadata and indexes
- Q&A history
- User and permission history
- Audit logs
- Legal holds
- Deletion confirmation
A good on-premise VDR or SaaS VDR should still let you prove what happened in the room after the transaction ends.
10. What should the commercial and assurance package include?
Price matters, but only after control fit. Ask for:
- Base room fee
- Storage limits
- User and guest charges
- Export fees
- Archive charges
- Region charges
- Support and implementation fees
- Renewal terms
Also request:
- ISO certificate scope
- SOC report type and period
- Pen-test summary
- Vulnerability policy
- Subprocessor list
- Business continuity summary
- Incident response policy
- Privacy terms
- Deletion process
DCirrus publicly describes predictable pricing and per-GB billing language, but there is no public transaction-specific price card in the dossier. Do not guess at savings claims.
What deployment model fits most sensitive transactions?
For most merchant bankers, the best default is a governed SaaS model with India-appropriate data-location controls, strong contractual commitments, exportable audit evidence, and clear incident terms. That gives speed, lower operating burden, and easier scaling across multiple deals.
Choose a customer-managed cloud when the client needs the cloud account, network boundary, encryption keys, or security monitoring to sit under customer control.
Choose an on-premise VDR only when there is a documented sovereignty, air-gap, client-policy, or infrastructure requirement and the firm can carry the added work of patching, monitoring, recovery, and external access.
Responsibility matrix
| Activity | Merchant banker | IT/CISO | Deal admin | DCirrus or deployment operator | Client/legal advisers |
|---|---|---|---|---|---|
| Data classification | Accountable | Consulted | Consulted | Informed | Consulted |
| Deployment selection | Accountable | Responsible/consulted | Consulted | Consulted | Consulted |
| Permissions and approvals | Accountable | Consulted | Responsible | Provides controls | Request or validate access |
| Log retention and export | Accountable | Responsible | Executes exports | Provides logs and retention controls | Receives evidence |
| Incident response | Accountable | Responsible | Escalates events | Detects and supports | Provides context |
| Retention and deletion | Accountable | Responsible | Executes closure | Performs contracted deletion | Confirms instructions |
Common failure modes to avoid
Watch for these mistakes:
- Treating data residency as full compliance
- Assuming encryption means customer control
- Giving external users broad access
- Using shared accounts
- Relying on a dashboard instead of exportable evidence
- Ignoring provider-admin access
- Treating DRM as absolute protection
- Closing the room before retention is settled
These are the issues that usually create the real risk in a regulated enterprise VDR program.
Summary and Next Steps
Do not approve a VDR deployment until every critical control has a named owner, a clear operating model, and a testable evidence trail. The best deployment is the one that matches the transaction’s sensitivity and the firm’s ability to run the controls properly.
For most regulated merchant bankers, that means a governed SaaS default. For higher-control cases, it means customer-managed cloud. For genuine sovereignty or air-gap needs, it means on-premise VDR with the operational investment to match.
