1. What this policy covers
This policy explains how DLD Portal (“DLD”, “we” or “us”) handles account information, company records and access to the service. It describes the currently deployed portal and distinguishes working controls from services that are not yet activated.
Each subscribing company controls the operational information it enters and the people it authorises to use its workspace. People entering information about employees, customers or other contacts should have authority to do so.
Policy details awaiting confirmation: the operator’s legal identity and hosting/processing countries have not yet been confirmed for this page. The access practices below are current; this policy’s administrative details will be updated when confirmed.
2. Information collected and how it arrives
- Account and company information: names, email addresses, company details, roles, account status, subscription/trial information and password hashes.
- Public enquiries: the name, email, topic and message you submit through the contact form, plus a hashed network address for submission throttling. This information is shared with the service operator to handle your enquiry or privacy request; it is separate from company workspace access approval.
- Operational records: customer/contact details, job sites, suburbs and routes, dates, dockets, weights, rates, costs, hours, fuel, rebates, notes and invoice/RCTI information entered by company users.
- Source and migration information: original records, source identifiers and audit history where a company authorises a migration.
- Security and activity information: session details, sign-in attempt records, timestamps, IP addresses recorded with audit activity, access approvals and change history. The hosting service may also maintain technical access/error logs.
- Payment-provider references: when Stripe is activated, provider customer/subscription identifiers and subscription/payment status. The portal does not store full card numbers or card security codes.
Information comes from signup forms, authorised company users, an arranged migration, use of the service and—when enabled—verified payment-provider events. Screenshots on the public website use fictional records.
3. Why information is used
We use information to create and authenticate accounts, keep company records, calculate and preserve charges, provide reports and exports, manage trial/subscription access, handle authorised support and maintain security and backups.
Private operational records are not available to other subscribing companies. The explicit exception is the shared reference library: user-confirmed Boral site names, origin/destination suburbs and states, paid kilometres and confirmation dates are visible to signed-in tenants alongside shared Boral rate cards. Dedicated contractor-ID/contact fields, loads, invoices, costs, private rates and notes are excluded; public site/suburb labels can still identify a person or business. The portal does not automatically send your dockets, loads, RCTIs or backpay estimates to Boral. Any sharing through a downloaded report or invoice is controlled by the person exporting or sending it.
The current public pages do not embed advertising trackers or third-party analytics. Essential cookies support sign-in, form security and the hosting service’s automated-request checks. We do not use the portal to sell company operational records or create a public customer directory.
4. Who can access company records
| Person | Portal access |
|---|---|
| Your company Owner | All company operational information, user management and support approval/revocation. |
| Your company Data Entry user | All company operational information and financial totals, including activity entry, reconciliation and invoicing. No user management or support approval. |
| Another subscribing company | No access to your private operational workspace; shared confirmed route references and rate cards are visible. |
| Platform support administrator | No routine operational access unless your company Owner explicitly approves a request. Approved access is limited by scope and time. |
The central Boral rate cards and user-confirmed Boral route references are shared. Approved confirmed routes from the original Access database are shared. Newly added routes publish only when paid KM are confirmed and the separate sharing checkbox is selected. Shared fields are the site label, suburb pair, states, paid KM and confirmation date. Approved Access references can show UNKNOWN where states were not recorded; new shared routes require both states. Dedicated contractor-ID/contact fields, dockets, notes, private rates, fuel, hours and audit records are not in the shared projection. Site/suburb labels are free text and can still identify people or businesses; use suitable public reference labels only. Unconfirmed estimates are not shared. Source-confirmed Access routes were approved for sharing by the service owner; new routes require a separate sharing choice. Unticking sharing, unconfirming or deactivating your source route withdraws that contribution; copies already adopted by other contractors and independent confirmations remain. Each company keeps its own local route copy.
Platform administration can view the company/account metadata needed to administer the service, such as company names, workspace/subscription status, plan prices and aggregate account counts. This does not grant access to company operational records.
5. Company-approved platform support
- Platform support submits a request identifying the company, reason and requested scope.
- A company Owner approves or declines the request. A Data Entry user or the platform requester cannot approve it.
- Read-only approval permits viewing. Editing requires a separate explicit edit approval.
- Approval expires 24 hours after approval. The Owner can revoke it earlier.
- The server checks the active approval on each operational request, including exports and form submissions. Approved portal access is recorded in the company audit log.
Support tickets and replies are intentionally shared with the DLD support team and your company users. The team can read that submitted conversation without opening your operational workspace. Tickets can contain personal information you type; include only what is needed and do not send passwords or card details. Ticket replies appear in the portal, not by email. Signup, payment, sending a ticket or platform-admin status does not imply operational support approval. Support approval does not grant user management or password-reset access. Your Owner retains control of those actions.
Read the support access guide for the approval and revocation steps.
6. Hosting, database and backup access
Company approval controls access through the DLD application. The database, application files and private backups are held on the hosting account.
Hosting-level or database-level administrators may have the technical ability to access this infrastructure independently of the portal. Portal approval is not a technical barrier against a privileged hosting-account operator. This policy does not claim end-to-end encryption, independently encrypted company databases or an infrastructure system that is physically unable to read records.
Routine support through the portal must use the company-approval process. Infrastructure access for authorised maintenance, security response or recovery is a separate matter and should be limited to the work required. An operational support grant is not permission to publish or reuse company records.
Panthur is the hosting provider, confirmed by the service owner. Account-specific storage/backup locations and provider support/processing countries still need confirmation. We do not currently promise that all information remains in Australia. Location details will be added after the operator confirms them.
7. External services and disclosures
Road-distance estimates
When you request a road estimate, the server sends the suburb/state search to OpenStreetMap Nominatim and sends route coordinates to OSRM/FOSSGIS routing. These providers receive the route-query information and the DLD server’s network request information. Customer names, docket details, tonnes and invoice amounts are not included in those estimator requests.
These services have their own handling practices. The OpenStreetMap Foundation’s policy describes personal-data storage in the United Kingdom and the Netherlands, with backups in the EU. See the OpenStreetMap Foundation privacy policy and FOSSGIS privacy information. Estimates are cached within the company scope.
Stripe subscription payments
Stripe payment collection is being activated. When available, subscribing Owners will use Stripe-hosted checkout. Stripe may receive billing/contact details and company identifiers and will handle the payment information entered there. DLD receives provider references and verified subscription/payment status; full card details are not stored in DLD. Stripe’s policy describes international transfers, including to the United States and India. See Stripe’s privacy policy.
Other disclosures
A company can export its own records and share them with its advisers. Information may also need to be provided in response to a lawful requirement or to address a security incident, with the circumstances assessed individually. We do not describe the routine support approval process as preventing legally required disclosures.
8. Security measures and your responsibilities
The portal uses HTTPS, secure session cookies, password hashing, session expiry, sign-in throttling, form security checks, company-scoped queries and audit records. Published rate cards preserve their values, and saved load charges are retained unless deliberately recalculated.
Company Owners should manage active users, use individual accounts, share temporary credentials privately and review support requests before approving them. Users should keep passwords private and sign out on shared devices. Downloaded CSV files, invoices and backups leave the portal’s access controls and should be protected by the person downloading them.
These measures reduce risk but are not a guarantee against every security incident. Multi-factor authentication and offsite backup are not currently advertised as enabled features.
9. Retention, cancellation and backups
After cancellation, company records remain available for viewing and export for six months; edits are paused. After that window the account enters an admin retention-review queue. Company accounting/operational records are not automatically erased. Dispute, security and legal record-keeping needs are reviewed before deletion.
Resolved support tickets and their messages are retained for two years after resolution. Public contact enquiries are retained for two years after closure. A legal/dispute hold prevents scheduled deletion. Reopening resets the closure clock. Records closed before closure dates were recorded use the rollout date conservatively.
The daily maintenance job removes eligible closed records after backup. Private DLD-managed full-server backups rotate after 30 days; a deleted item can remain in earlier backups until they expire. This is not a promise that all copies or record types disappear after 30 days. Provider backups, exports, company-triggered backups, source archives and local migration/development files have separate handling.
Removing a mistaken load from operational records retains an audit snapshot and may leave source/backup copies. Shared references already adopted by other companies are separate local copies. Requests for access, correction or deletion require identity/authority checks and consideration of retention obligations; exported files cannot be remotely erased.
The operator identity, full record-type schedule and provider details still need final review. No fixed deletion period is claimed for every category of live accounting/source/audit data.
10. Access, correction, export and deletion requests
Company users can view and edit authorised records in their own workspace and export reports. Owners can download a private workspace backup. A person seeking access to or correction of personal information should first contact the company Owner where the information was entered by that company.
For information held by the service operator, or where an Owner cannot resolve the request, use the DLD privacy request form. Include the account/company involved, the type of request and enough detail to identify the information. Do not send passwords or full card information.
We may need to verify identity and authority before providing information or making changes, and must avoid disclosing another person’s information through a request. A deletion request does not automatically remove accounting history or records subject to a retention requirement.
The contact form is available now. The operator’s legal identity and any additional public contact details will be added when confirmed. Company Owners can continue to manage workspace access and operational corrections in the portal.
11. Questions, complaints and changes
Raise a privacy question or complaint through the DLD privacy complaint form. Describe the issue and the outcome you are seeking. The service target is acknowledgement within five business days (Monday–Friday excluding configured service holidays) and a substantive response within 30 calendar days. If more time is needed, the reason and revised target are explained. These are service targets, not a guarantee every request is completed in 30 days. Admin records acknowledgement, response and any extension; this does not send an automatic email.
If the matter is not resolved, you can review complaint options with the Office of the Australian Information Commissioner, where its jurisdiction applies. This page does not assert that the operator has been certified by, or formally registered with, the OAIC.
We will update this page when confirmed operator details or material service practices change. The revision date identifies the current version.
Policy structure informed by the OAIC’s guidance on transparent privacy policies. DLD’s actual practices, rather than a general compliance claim, are described above.