Government requests, published openly.

This is TenderPulse’s first annual Transparency Report. It covers the 12 months from 1 May 2025 to 30 April 2026. The report includes:

• Total number of government requests received
• Source of requests (BTRC, Bangladesh Police, ACC, court order, foreign authority)
• Categorisation of requests (user data disclosure, content takedown, account preservation, real-time monitoring)
• Outcome (complied in full, complied in part, refused, withdrawn, in process)
• Number of users affected (where lawful to disclose)
• Number of requests we challenged or sought clarification on
• Number of gag orders we received and the count we successfully challenged

We will publish a fresh report annually within 30 days of the end of each reporting period. Where new categories of requests arise (e.g. AI-related disclosure orders) we will add columns as needed.

Number of users affected by complied-with requests: 1 (the user notified within 30 days as required under Digital Security Act 2018 §32).

Number of gag orders received: 0. Number challenged: 0.

In December 2025 we received a request from Bangladesh Police for user information related to a specific account. The request was made by phone call to a TenderPulse staff member. The staff member followed our protocol: declined to action the request, referred the requester to help@tenderpulse.com.bd, and reported the contact to our Compliance Officer the same day.

We responded by requesting that the police submit the request in writing on official letterhead, citing the specific statutory authority and naming the authorising officer. As of the close of the reporting period, no formal written request had been received. We treated this as a withdrawn request.

The user whose account was the subject of the call was not notified, on the basis that there was no formal request to action and no investigation we were aware of was underway. We will revisit this if formal documentation arrives.

BTRC content takedown notice (July 2025). The notice referenced a specific public-facing page on the apex marketing site that the BTRC believed was misleading about a government procurement programme. On internal review we agreed the page contained an outdated and misleading factual claim, updated the page to correct the claim, and notified the BTRC of the change. The user impact was zero (the content was marketing, not user-facing data).

Court order (October 2025).A District Sessions Court issued an order in connection with a tender-fraud investigation requiring TenderPulse to disclose audit log entries relating to a specific account’s activity on a specific tender. The order met our formal-validity checklist (court letterhead, named judge, statutory authority, specific scope). We complied within the 21-day window stated in the order. The affected user was notified on the same day we complied; no gag was attached. The user retained the right to challenge the underlying investigation through their counsel.

Our internal protocol for every government request:

1. Formal-validity check — official letterhead, authorised signature, named requesting officer, specific statutory authority cited
2. Scope review — is the request narrowly drawn? Over-broad requests get pushed back with a request for specific scope
3. Independent counsel review — for any request we are uncertain about, we engage external counsel before responding
4. User notification analysis — can we notify the user? If gagged, is the gag legally valid? Can we challenge it?
5. Compliance scope — we provide only what was specifically requested, not what would be convenient. No data goes beyond the documented scope.

Methodology notes for this report:

• Source data— every request received is logged in our internal “legal request register” with date received, source, type, status, outcome, and outcome date. Only requests recorded in this register count.
• Counted as “received” — any request reaching us in writing, even if subsequently withdrawn. Phone calls and oral approaches are not counted until formalised (the December 2025 phone request was not counted because it was never formalised).
• Counted as “complied” — requests where we provided some or all of the information sought. Partial compliance counts as compliance for this purpose.
• Counted as “refused” — requests where we declined to provide any of the information sought, whether on validity grounds or substantive grounds.
• Counted as “challenged” — requests where we sought formal review of the request through counsel, court application, or regulator-level pushback.

Limitations: this methodology is consciously simple for our first reporting cycle. Future reports will introduce more granular fields (data-volume disclosed, time-to-respond, user- notification rate) as the volume of requests warrants.

We have not received any national security letters, pre- publication gag orders, or any classified/secret-classified requests during this reporting period. Should we receive any such request in the future, our policy is to:

• Challenge the gag where any legal route to challenge exists
• Where the gag is binding, publish a “warrant canary” -style indicator in this report disclosing the existence of the request without disclosing specifics
• Notify the affected user the moment the gag lifts

As of the date of this report, no such gag orders are in effect. The absence of a warrant-canary statement at the bottom of this section is itself a meaningful signal under our protocol.