Most Structured Digital Database (SDD) failures aren’t caused by teams that didn’t try. They’re caused by workflow design failures: unclear triggers, incomplete identity fields, and no one accountable for making entries on time. When your VDR is processing access requests from multiple parties across dozens of UPSI-tagged documents, the logging gap grows daily.

The fix is to treat every VDR access event involving UPSI as a structured “sharing event” with a defined pipeline. This article gives you that pipeline, a simple responsibility model, and a guide to fixing the most common failure modes.

Why do VDR access events create SDD risk in the first place?

VDRs are high-volume environments. During due diligence, dozens of users may access UPSI-tagged documents in a single day. Each of those interactions is a potential sharing event for SDD purposes, but deal teams rarely treat them that way in real time.

The gap is operational, not intentional:

• Deal teams move fast, while SDD logging happens at the end of the week or later.
• Multiple users accessing the same document creates multiple entries that must be person-wise and time-stamped.
• UPSI is spread across folders, so not every access event is an obvious UPSI moment.

SEBI’s SDD expectations for completeness, immutable timestamps, and quarterly certification are clear. If your workflow doesn’t produce entries close to real time, you accumulate certification risk with every unlogged access event.

What’s the correct trigger: when does a VDR event become an SDD entry?

The trigger isn’t “formal disclosure.” It’s when UPSI is shared or accessed. This includes view, open, and download events in a VDR.

Use this decision rule:

• Is the document or folder tagged as UPSI (or known to contain it)?
• Is the user outside the core “already-in-the-know” group?
• Did they create a new access event (view, open, download)?

If yes to all three, create an SDD entry.

In practice, viewing a document in a VDR is enough to constitute access to UPSI. You don’t need a formal transmission event.

Your default target for timeliness should be same-day or within 24 hours. Late entries are allowed but must include the actual sharing timestamp (not the logging date) and a documented reason for the delay. Making late entries without noting the reason creates more audit risk than the delay itself.

What fields must you capture from VDR logs to make an SDD entry audit-ready?

VDR logs give you timestamps and user activity, but they don’t automatically provide everything an SDD entry needs. You have to map VDR data to SDD fields.

Capture these minimum fields for each entry:

• Person identity: Full name plus PAN (or a documented alternative if PAN is unavailable), linked to the VDR user account.
• Date and time of access: The immutable timestamp from the VDR log, not one entered manually.
• UPSI reference: Document name or ID, plus the category of UPSI involved (e.g., financials, draft offer document, deal terms).
• Source and recipient context: Who granted access and who accessed it.
• Purpose of access: Due diligence, legal review, underwriting, etc.
• NDA/confidentiality confirmation: Whether the person is covered and when the agreement was executed.

Person-wise logging is essential. If five users access the same document, you need five distinct SDD entries. A single group entry will not hold up in an audit.

Never overwrite an entry. If you need to make a correction, append a new entry with the reason and a reference to the original record.

A VDR with comprehensive audit trails and granular access controls makes this mapping much easier. For example, DCirrus VDR tracks every user action with timestamps and records who accessed what under which permissions. This gives you a reliable evidence base to use when writing SDD entries. It doesn’t create the entries for you, but it removes the guesswork from the “who accessed what, when” question.

What is the 7-step workflow to connect VDR access events to SDD entries?

This is the core pipeline. Run it on every active deal room.

Step 1: Tag UPSI at the document and folder level

• Agree on what qualifies as UPSI for the deal before due diligence opens.
• Apply UPSI tags at the folder level where possible and flag individual documents where needed.
• Maintain a simple tag system (e.g., Financials, Deal Terms, Draft Offer Docs).

Step 2: Configure which access events to capture

• Focus on view, open, and download events for UPSI-tagged content.
• Avoid logging everything. Untargeted capture creates noise and dilutes accountability.
• Define which folders are in scope before access begins.

Step 3: Validate user identity before access is granted

• Map every VDR user account to a real person with a confirmed PAN or other ID.
• Block shared logins. Each user must be individually identifiable.
• Confirm NDA status at onboarding, not after access.

Step 4: Create a person-wise sharing event record

• One access event means one SDD line item per person, per document.
• Include the UPSI reference, the timestamp from the VDR log, and the purpose of access.
• Person-wise entries are non-negotiable. Don’t batch them by session or document.

Step 5: Apply maker-checker controls

• The nodal officer for the relevant function creates the entry.
• The compliance officer reviews exceptions and flags incomplete records.
• Aim for same-day entry, with a 24-hour maximum turnaround.

Step 6: Handle multi-party and cascaded sharing

• If an external advisor shares UPSI onward (A → B → C), each leg requires a separate entry.
• For legs you can’t directly observe, rely on confirmations from counterparties or fiduciaries.
• Document the confirmation method and date.

Step 7: Reconcile monthly for quarterly certification readiness

• Pull VDR access logs for all UPSI-tagged content.
• Match each access event to an SDD entry. Log any gaps with closure dates.
• Review the reconciliation pack with the compliance officer before each quarter closes.

Who should own each step in a merchant banking deal team?

Compliance can’t log every access event. You need a clear ownership map.

• Compliance Officer: Owns the SDD SOP, oversees entries, coordinates quarterly certification, and handles escalations.
• Deal Lead: Ensures external parties complete NDAs and identity validation before VDR access is granted.
• Nodal Officers (by function): Responsible for confirming UPSI creation and sharing events in their area and ensuring entries are made on time.
• IT/Admin: Enforces user provisioning standards, conducts periodic access reviews, and prevents shared logins.

A simple operating cadence:

• Weekly: Review exceptions like incomplete entries or late logs.
• Monthly: Conduct spot checks and prepare the reconciliation pack.
• Quarterly: Prepare for certification with a final review by the compliance officer.

One governance principle is key: design access on a need-to-know basis. Fewer people with access to UPSI means fewer access events to log, which reduces the risk of both leaks and compliance gaps.

What are the most common failure modes and what should you do when they happen?

Expect mistakes. A defensible SDD record is separated from a problematic one by having a documented fix for each failure.

• Late logging: Record the actual sharing timestamp, not the logging date. Add a brief, factual reason for the delay. If it happens repeatedly, tighten your SLA.
• Missing or incorrect PAN/identity: Enforce identity validation at onboarding. Block access until minimum ID fields are confirmed. If you find an error, retroactively document the correct identifier with a reference note.
• Overwriting or editing entries: Never edit an existing entry. Append a correction that references the original and explains the change.
• Over-logging noise: Revisit your UPSI tagging and trigger rules. If you are creating entries for non-UPSI documents, tighten your folder-level tagging.
• Uncontrolled downloads or forwarding: This is where VDR access controls become a compliance input, not just a security feature.

DCirrus VDR’s DRM controls, granular permissions, and dynamic watermarking help reduce the chance of a VDR access event becoming an uncontrolled redistribution. These controls embed user information, IP addresses, and timestamps on documents. While this doesn’t guarantee zero leaks or replace SDD maintenance, it narrows the gap between “UPSI was accessed” and “we know where it went.”

How do you prepare for quarterly certification using VDR evidence?

Build a monthly reconciliation routine so certification isn’t a fire drill.

Each month, produce a reconciliation pack that includes:

• Top UPSI-tagged folders and documents accessed.
• A full list of users who accessed each, with VDR-sourced timestamps.
• Your match rate: how many access events have a corresponding SDD entry.
• A gap list of unmatched events, with closure dates and documented reasons.

Use random sampling (even a small, consistent sample) to demonstrate control effectiveness to auditors. A 100% reconciliation claim is harder to defend than a documented sampling methodology with clear exception handling.

DCirrus exportable reports give you a structured starting point for this process. The audit trails provide the per-user, per-document data you need for sampling. You will still need to match those records to your SDD manually, as there is no built-in SEBI certification output, but the underlying evidence is already organized and exportable.

Summary and Next Steps

SDD failures are almost always workflow failures. The workflow described here makes compliance repeatable. Tag UPSI, define triggers, validate identity, write person-wise entries, use maker-checker controls, handle cascaded sharing, and reconcile monthly.

If you do one thing first, define your UPSI tagging and the “access event → person-wise entry within 24 hours” rule. Pilot it for two weeks on one deal room. Use the data on your gap rate and time-to-entry to tune your process before the next certification cycle.

FAQ

Do we need an SDD entry for internal access within the same organization? Yes, if the person accessing UPSI was not previously aware of it. The “already-in-the-know” exception only applies to those already holding the information. Sharing that extends UPSI to a new person inside your organization still requires an entry.

If five investors access the same UPSI document, is it one entry or five? Five entries, one per person. SDD requires person-wise records for individual accountability and traceability. Each entry must have that person’s identity, their access timestamp, and the UPSI reference.

What if UPSI is shared in parts across multiple documents? Each sharing event is a separate trigger. If UPSI is fragmented across communications, document each instance individually. The cumulative picture matters for audit purposes.

How should we handle onward sharing by external advisors? Each leg of onward sharing requires its own SDD entry. For sharing you can’t directly see, rely on written confirmation from the fiduciary or counterparty. Log the confirmation method, the date, and the individuals covered.

Can the SDD be hosted on the cloud? Yes. SEBI’s Structured Digital Database requirements focus on completeness, access control, and immutability, not hosting location. Cloud hosting is fine, provided the controls meet the standard.

Are spreadsheets acceptable for SDD maintenance? They are common but risky. The main concern is the immutability requirement, as spreadsheets can be edited without a trace. If you use Excel, you need extra controls like version locking, access restrictions, and a documented audit trail for changes.

What’s a practical “late entry” note that won’t create more risk? Keep it factual and brief. State the actual date and time of the sharing event, note the date the entry was created, and give a short reason for the delay (e.g., “Entry created on [date]; sharing occurred on [date]. Delay due to [reason].”). Honesty about the timeline is key. Auditors are more concerned with accuracy than speed if the delay is acknowledged.