An e-tendering system should control access to sealed bids through project-specific permissions, opening conditions and protected file delivery. A buyer may need to confirm receipt without seeing prices. A system administrator may manage accounts without automatically gaining the right to open bids. When comparing software, ask providers to demonstrate these boundaries with different accounts and make the results part of acceptance.
This article addresses sealed bidding in business procurement, including teams operating in Vietnam. The procedure for a particular tender must follow its applicable rules. The permission model below is a proposed purchasing requirement, not a national statutory procedure or a claim about an existing product.
Separate receipt information from bid content
Break “view bids” into specific actions: checking submission status, viewing bidder identities, previewing files, downloading attachments, reading prices, exporting comparisons and changing opening times. Assign each action to a project and a stage rather than granting a single broad procurement-administrator permission.
A buyer might check whether a submission was received or help resolve an upload failure without accessing its pricing. An evaluator can be assigned to a project in advance while document access remains closed. Suppliers should manage only their own submissions. Whether bidder identities or submission counts are visible is another decision to record explicitly.
For a two-stage procedure, specify separate release conditions for technical documents and commercial prices. Starting technical evaluation should not automatically expose price attachments reserved for a later stage.
Define permissions by role, project and stage
Use the following boundaries as a starting point for requirements discussions:
Supplier: submits or withdraws its own material under the agreed rules and views its own receipt; has no access to another bidder’s files.
Buyer: manages the project and receipt workflow without reading protected prices or attachments before opening.
Evaluator: accesses only assigned projects and document types after authorized opening.
System administrator: maintains accounts and configuration without automatically receiving business rights to open, decrypt or download bids.
Auditor: reviews the necessary activity records; access to logs and access to bid contents are granted separately.
Access model: reaching the opening time is followed by authorized confirmation and release of the specified files. Roles and the required number of confirmations depend on the project rules.
Ask providers to explain the limits of administrator restrictions. A blocked application screen does not establish that privileged operations staff cannot read stored files. If your requirement includes protection against early access by such staff, request a documented storage, encryption, key-custody and emergency-access design. Identify who retains technical access. Application permissions and stronger sealed-bid protection are different delivery commitments.
Enforce opening conditions beyond the button
Model submission closure, waiting for opening, authorized opening, evaluation and archiving separately. Closing submissions does not necessarily complete opening. Even after the scheduled time, any agreed authorization conditions must still be met. Where multiple confirmations are required, demonstrate that one missing confirmation keeps the files closed.
For teams in different locations, use a consistent time reference on project pages, notifications and exported records. A postponement also needs to affect scheduled tasks and cached permissions. Ask the provider to demonstrate a page opened before a postponement and used afterward; the restriction should not depend solely on refreshing the screen.
Protection must extend to preview, download and export paths. The OWASP Authorization Cheat Sheet recommends denying unauthorized access by default and checking permissions on every request. Accordingly, acceptance should include evidence from an authorized test environment that file access is restricted, rather than relying only on hidden menus or disabled buttons.
Include download links and activity records
A download address is not automatically restricted to the person who first received it. For example, AWS’s S3 presigned URL documentation explains that possession of such a link grants access within its validity conditions. If a proposed system uses this mechanism, establish when links are issued, how long they last, whether they can be shared, and what happens to issued links after a role is revoked or opening is postponed. Logging out is not proof that a download link has stopped working.
Request records that identify the actor, project, file, action, time and allowed or denied outcome, together with important changes to roles and opening schedules. Logs should not reproduce complete offers or expose passwords, keys or usable download credentials. Protect the records against unauthorized access and alteration; the OWASP Logging Cheat Sheet provides relevant design guidance.
Have the provider show a denied early-access attempt and a successful opening, linked to the same demonstration project. Login timestamps alone cannot establish which material someone accessed or the result of an attempted action.
Test six scenarios before acceptance
Prepare demonstration project DEMO-01, two fictional suppliers, and buyer, evaluator and administrator accounts. Use non-sensitive sample files. Record expected results first, then have the provider run the tests and supply evidence.
Early access: before opening conditions are met, buyers and evaluators cannot obtain protected files, while permitted receipt information remains available.
Supplier separation: supplier A cannot access supplier B’s documents or obtain its prices through an export.
Incomplete authorization: where multiple confirmations are required, reaching the opening time without enough confirmations keeps files sealed. Once conditions are satisfied, only the specified files are released.
Postponement and revocation: after changing the opening time or removing an evaluator, test existing pages and previously issued download links against the agreed behavior.
Repeated actions and failures: repeated opening requests do not produce conflicting states. An inability to establish permission or timing conditions must not be treated as permission to access files.
Traceability and export: export the demonstration’s authorization, refusal, opening and download records. They should reconstruct events without revealing bid contents or access credentials.
For each scenario, retain the expected result, actual result, evidence, gap and responsible owner. These are proposed acceptance tests, not completed product testing. Classify undemonstrated capabilities as pending confirmation and establish whether delivery requires an existing feature, configuration or additional development.
If you are still defining the wider scope, start with selecting procurement and tendering software in Vietnam. For internal requests, approvals and role administration, review HUACODE’s OA Office Management System. Its published approval, permissions and logging features do not establish support for sealed bids or timed decryption.
Bring your role list, opening conditions, document categories and confidentiality requirements to a HUACODE requirements consultation. Asking providers to demonstrate the six scenarios makes the delivery scope clearer than asking only whether they support access control.
Sources checked on 25 October 2026. The cover depicts an illustrative procurement collaboration scene.