Security Overview

BordersHub holds information that organizations rely on to decide whom to do business with, including compliance evidence they share only with partners they trust. This overview describes the safeguards built into the Service and the responsibilities that remain with each organization.

1. Our approach

Every organization’s information is private by default. Access is granted deliberately—by an organization to its own team members with defined roles, and by an organization to specific partners it approves—and every significant access is recorded. Security controls are enforced on the server for every request, not only in the user interface.

2. Account protection

• Password storage. Passwords are never stored in readable form. They are stored as salted, iterated cryptographic hashes (PBKDF2) using the ASP.NET Core Identity framework.
• Password policy. Each organization’s administrators can set a minimum password length and require special characters for their members.
• Brute-force protection. Accounts are temporarily locked after a configurable number of failed sign-in attempts. Failed attempts and lockouts are recorded in the audit log.
• Multi-factor authentication. Users can protect their accounts with a time-based one-time password (TOTP) authenticator app. MFA is mandatory for every organization administrator, and administrators can make it mandatory for everyone in their organization; users who must use MFA are required to set it up before they can continue.
• Session invalidation. Removing a member, resetting their MFA or changing a password invalidates the account’s existing sessions, which are signed out at their next periodic security check (within 30 minutes). Evidence downloads do not wait for that check: they re-verify the account against the database on every request, so a removed member cannot download evidence with an old session.
• Account recovery. Password reset links generated by an administrator expire within 24 hours and stop working once used.

3. Access control and isolation

• Organization isolation. Every record is scoped to the organization that owns it, and every query for non-public information is restricted to the requesting organization or to organizations that have approved it.
• Roles. Members are assigned roles (Admin, Contributor, Approver, Governance, InfoSec, Risk, Auditor, Sales, Read-only or Billing user) that limit which sections they can open and what they can change there. Only administrators can manage the team, settings and API tokens; only administrators and billing users can manage the subscription.
• Joining an organization. Someone who registers with an email address at an organization’s company domain doesn’t get access: their account stays inactive, without a role and unable to sign in, until one of that organization’s administrators approves it and chooses the role. Addresses at public email providers never match an organization. Approvals and rejections are recorded in the audit log.
• Removed members. Removing a member disables their account immediately. Only an administrator of the same organization can restore it or delete it, and both actions are recorded in the audit log.
• Internal approval workflow. A trust profile version is published only after it has been submitted and approved inside the organization, and each approval records who approved it, in what capacity and when.
• Least disclosure in public. The public registry entry deliberately omits sensitive identifiers such as registration numbers and incorporation dates, and never includes declarations or evidence.

4. Controlled sharing

• Another organization can see your full trust profile and evidence only after your organization approves its trust request. Approval is one-way: it does not give you access to theirs.
• Approvals can be revoked at any time, and revocation takes effect immediately for all further access, including through the API.
• Every time a partner opens your full trust profile or downloads an evidence file, the event is recorded in your audit log and in theirs.

5. Evidence files

• Evidence files are kept in private storage and are never exposed through public or guessable links. Every download passes through the application, which checks the requester’s permission at that moment.
• Requests for files a requester is not entitled to receive the same “not found” response as files that do not exist, so links do not reveal whether a file exists.
• Downloads are sent with headers instructing browsers, proxies and content delivery networks not to cache them.
• Evidence can carry an expiry date, and the Service highlights evidence that is about to expire or has expired.

6. Audit logging

• The Service records sign-ins and failed sign-ins, account and security setting changes, team changes, trust profile edits, submissions and approvals, evidence uploads, views and downloads, trust decisions, API token management, subscription and billing events (payments, renewal changes, refunds and chargebacks), and support activity.
• Each record captures what happened, when, who did it (including their organization, if it was a partner), and from which IP address and browser.
• Audit records are append-only. The application refuses to modify or delete them, and the database itself rejects any attempt to modify them. They are removed only when the organization they belong to is deleted.
• Administrators can search and filter the audit log in the Service and retrieve it through the API.
• Actions taken by BordersHub staff, such as answering support tickets, reviewing reports, removing content and suspending accounts, are recorded in a separate append-only staff activity log and, where they concern your organization, also in your audit log as “BordersHub Support”. Staff use named accounts with multi-factor authentication.

7. API security

• API tokens are created only by organization administrators. Each token is generated with approximately 238 bits of randomness, shown once at creation and stored only as a SHA-256 hash, so it cannot be recovered from our systems.
• Tokens expire no later than one year after creation and can be deleted at any time, taking effect immediately. Administrators can see when and from which IP address each token was last used.
• The API is read-only and applies the same access rules as the web application. It accepts only API tokens, not browser sessions, which protects it from cross-site request forgery. It works only while the organization has an active subscription; otherwise tokens are refused.
• Each token is rate limited, and token creation and deletion are recorded in the audit log.

8. Infrastructure and data protection

• Encryption in transit. The Service is served over HTTPS using TLS, and browsers are instructed through HTTP Strict Transport Security (HSTS) to connect only over HTTPS.
• Encryption at rest. Where offered by our hosting and storage providers, stored data is encrypted at rest using provider-managed keys.
• Hosting. Data is hosted in Canada with established cloud infrastructure providers. When cloud object storage is used for files, the storage bucket is private and files are served only through the application.
• Minimal third parties. The Service does not embed third-party analytics, advertising or tracking scripts. The only third-party script is Paddle’s checkout, loaded only on the Subscription page.
• Payments. Subscriptions are paid to Paddle, our reseller and merchant of record, in Paddle’s own PCI DSS-compliant checkout; card details never reach BordersHub’s servers. BordersHub confirms each payment with Paddle server-to-server using a secret key, and accepts Paddle’s notifications only with a valid signature (HMAC-SHA256) and a recent timestamp. Paddle credentials are kept out of the code and the database, in the hosting provider’s secret store.
• Least privilege. The application runs as a non-administrative user, and access to production systems is limited to personnel who need it, with multi-factor authentication.
• Backups. The database and uploaded files are backed up automatically every day and backups are kept for 30 days, with a documented restore procedure.

9. Application security

• Database access uses parameterized queries through an object-relational mapper, protecting against SQL injection.
• Pages encode output by default, protecting against cross-site scripting, and forms are protected by anti-forgery tokens.
• Authorization is enforced on the server for every page, form submission, file download and API request.
• Uploaded support attachments are restricted to an allow-list of file types.
• Every code change is built and tested automatically and scanned with open-source tools: Trivy (vulnerable dependencies, leaked secrets, misconfiguration and the container image), Semgrep (static analysis) and the NuGet vulnerability audit. High and critical findings block the change. Dependabot proposes dependency updates weekly, and security fixes are applied within defined timelines.

10. Data deletion

An organization’s administrators can delete the organization at any time. Deletion immediately and permanently removes its trust profiles, evidence files, trust relationships, support tickets, reports it filed, API tokens, subscription history, audit log and member accounts, and cancels its subscription with Paddle. Reports other organizations filed about it, and BordersHub’s staff records of actions taken, are kept as described in the Privacy Policy. Residual copies in backups are overwritten in the ordinary course within 90 days. See our Privacy Policy for details.

11. Incident response

We investigate suspected security incidents promptly. If an incident affects your organization’s data, we will notify your organization’s administrators without undue delay, provide the information reasonably available to us to help you meet your own obligations, and notify regulators and individuals where the law requires.

12. Certifications

BordersHub does not currently hold independent security certifications or attestations such as SOC 2 or ISO/IEC 27001. Certifications, compliance statements and evidence shown in an organization’s trust profile belong to that organization, are declared by it, and are not verified or endorsed by LamWorks. Our self-attested controls, infrastructure providers and a pre-filled security questionnaire are published in our Trust Center.

13. Your responsibilities

Security is shared. Each organization is responsible for:

• enabling (and preferably requiring) multi-factor authentication and setting a strong password policy;
• granting roles on a least-privilege basis and promptly removing people who leave;
• approving trust requests only from organizations it has identified and intends to share with, and revoking approvals it no longer needs;
• keeping API tokens secret, giving them the shortest practical lifetime, and deleting tokens that are unused or may be exposed;
• reviewing its audit log regularly; and
• deciding what it uploads, and avoiding uploading information it is not permitted to share.

14. Reporting a vulnerability

If you believe you have found a security vulnerability in BordersHub, please report it to security@bordershub.com with enough detail for us to reproduce it. We will acknowledge your report, keep you informed of our progress, and credit you if you wish once the issue is resolved.

When researching, please:

• test only against accounts and organizations you own or have permission to use;
• not access, modify, download or retain other organizations’ data beyond the minimum needed to demonstrate the issue;
• not perform denial-of-service, spam, social engineering or physical attacks; and
• give us reasonable time to fix the issue before disclosing it publicly.

We will not pursue legal action against researchers who act in good faith and in accordance with these guidelines. We do not currently offer a paid bug bounty.

15. About this overview

This overview describes the Service’s security practices as of its effective date and is provided for information only. Our practices evolve, and we may update this overview accordingly. It does not create any warranty, commitment or obligation beyond those in our Terms of Service.