Sensitive Information Sharing Procedure¶


Distribution	Employees and Contractors; Clients upon request
Version	1.0
Approved	2026-02-25
Approved by	Ben Smith

Overview¶

The purpose of this policy is to establish a secure, standardised method for requesting and sharing secrets and sensitive information within FooEngine Ltd., hereafter known as 'the company'.

Secrets and sensitive information include, but are not limited to: passwords, API keys, access tokens, encryption keys, private certificates, database credentials, and any other data classified as Internal or above under the company's Data Classification policy.

This policy mandates the exclusive use of the company's password.link account as the approved tool for transmitting such information. Personal accounts, free-tier accounts, or any other password.link account must not be used. The use of email, instant messaging, shared documents, or any other unencrypted or persistent channel for sharing secrets is strictly prohibited.

Scope¶

This policy applies to all employees, contractors, and third-parties who need to request, share, or receive secrets and sensitive information in the course of their duties for the company.

This includes, but is not limited to, the sharing of credentials for production systems, cloud infrastructure, client environments, SaaS platforms, and any internal or external service requiring authentication.

What is password.link¶

password.link is a web-based service that allows users to share sensitive text securely by generating a unique, single-use, time-limited URL. The recipient opens the link, views the secret, and the link is then permanently destroyed.

The company maintains a dedicated password.link account for business use. All personnel must use this account when creating or requesting secrets. The account details and login credentials are available from the CTO or a designated administrator. Personal or free-tier password.link accounts must not be used for company business.

Key security properties of password.link include:

End-to-end encryption: secrets are encrypted in the browser before transmission and decrypted only by the recipient.
Single-use links: each link can only be opened once, after which the secret is permanently deleted from the server.
Configurable expiry: links can be set to expire after a defined period, even if not yet opened.
Password protection: links can be protected with an additional password, which must be communicated to the recipient via a separate channel.
Requesting feature: password.link provides a built-in mechanism for securely requesting secrets from others, generating a secure submission link that the holder can use to respond.
No account required for recipients: the service can be used by recipients without creating an account, reducing the attack surface.

Policy Requirements¶

Approved Tool¶

The company's password.link account is the only approved method for sharing secrets and sensitive information electronically. All links must be created using the company account - personal or free-tier accounts are not permitted. No other tool, platform, or method may be used for this purpose unless explicitly approved in writing by the CTO.

Prohibited Methods¶

The following methods of sharing secrets are strictly prohibited:

Email (including encrypted email, unless the secret itself is wrapped in a password.link URL)
Instant messaging platforms (e.g. Slack, Microsoft Teams, WhatsApp)
Shared documents, spreadsheets, or cloud storage (e.g. Google Docs, SharePoint, Dropbox)
Ticketing or project management systems (e.g. Jira, Asana, Airtable)
SMS or voice messages
Unencrypted file transfers
Verbal communication of complex credentials (where transcription errors and overhearing present risks)

Link Configuration Requirements¶

When creating a password.link, the following configuration requirements must be observed:

Burn after reading: all links must be configured for single-use (one view only). Multi-view links are not permitted. Once the recipient has viewed the secret, the link is permanently destroyed.
Password protection: all links must be protected with a password. The password must be communicated to the recipient via a different channel from the one used to send the link itself. For example, if the link is sent via email, the password should be sent via Slack, SMS, or a phone call.
Expiry time: links must be configured with the shortest practical expiry. A maximum expiry of 24 hours is permitted. For highly sensitive credentials (Client Top Secret or Client Confidential), a maximum expiry of 4 hours should be used.
Content scope: each link should contain only the minimum information necessary. Do not bundle unrelated credentials into a single link.

Requesting Secrets¶

When an employee, contractor, or third-party requires access to a secret or sensitive credential, the password.link requesting feature must be used. This feature generates a secure submission link that the holder of the secret can use to provide the credential safely, without the requester needing to disclose context about the secret in an insecure channel.

Procedure for the Requester¶

Log in to the company's password.link account.
Use the 'Request a Secret' feature to generate a secure request link. Include a brief description of what is being requested so the holder can identify the correct credential.
Send the request link directly to the person who holds the secret. The link must be sent only to the intended individual - it must not be posted into group channels, email threads with multiple recipients, or shared spaces where unintended parties could access it.
The request must not contain the secret itself, nor any partial representation of it (e.g. hints, last four characters) in any accompanying message.

Procedure for the Holder Responding to a Request¶

Verify the identity and authorisation of the requester before responding. For third-party requests, verification must be performed against a known contact list or confirmed via a secondary channel.
Open the request link and submit the requested credential through the secure form provided by password.link.
Confirm with the requester that the secret has been submitted so they can retrieve it promptly before the link expires.

Procedure for the Sender¶

Log in to the company's password.link account in a web browser.
Enter the secret into the text field. Do not include any identifying context (e.g. 'this is the AWS root password') within the secret payload itself - contextual information should be communicated separately.
Enable burn after reading (single-view) and set the expiry time as required by this policy.
Set a password on the link. The password must be sufficiently complex and must not be reused from other credentials.
Generate the link and copy the URL.
Send the link directly to the intended recipient only. Links must not be sent to group email threads, group chats, or any channel where unintended recipients could access them. Where an original conversation involves multiple parties, start a new direct message or email addressed solely to the intended recipient.
Send the link password to the recipient via a separate channel from the one used to send the link. For example, if the link was sent via email, send the password via Slack, SMS, or a phone call.
Confirm with the recipient that the link has been successfully opened and the secret retrieved. If the link has expired or been consumed by an unintended party, investigate immediately and treat the incident in accordance with the company's Incident Response Procedure.

Procedure for the Recipient¶

Open the password.link URL promptly upon receipt. Links are time-limited and will expire.
Copy the secret and store it securely (e.g. in an approved password manager or secrets vault). Do not save the secret in plain text on any device, document, or communication channel.
Confirm receipt to the sender so they can verify the link was consumed by the intended party.
If the link has already been consumed or has expired unexpectedly, notify the sender and the security team immediately, as this may indicate a compromise.

This policy addresses MPA Content Security Best Practice Control OR-3.4.

When sharing secrets with external third-parties such as clients, vendors, or subcontractors, additional precautions must be observed:

The identity of the recipient must be verified through an established and trusted channel before any secret is shared.
The password.link URL must be sent via a channel different from the one used to agree the sharing (e.g. if the request came via email, send the link via a verified mobile number or a separate authenticated platform).
Expiry times for third-party links should be set to the minimum practical duration, and should not exceed 4 hours.
A record of the sharing event (date, recipient, purpose, and classification of the information shared) must be logged for audit purposes.

Incident Response¶

This policy addresses MPA Content Security Best Practice Control OR-4.0.

The following events must be treated as security incidents and reported immediately in accordance with the company's Incident Response Procedure:

A password.link URL is found to have been consumed before the intended recipient opened it.
A secret is discovered to have been shared via a prohibited method (e.g. email, Slack message, shared document).
A password.link URL is shared publicly or to an unintended recipient.
A recipient reports that a link has expired or been consumed without their action.

In all such cases, the affected credential must be rotated immediately and the incident logged.

Compliance and Enforcement¶

All personnel are responsible for complying with this policy. Failure to comply may result in disciplinary action in accordance with the company's disciplinary procedures, up to and including termination of employment or contract.

Managers and team leads are responsible for ensuring their teams are aware of and trained on this policy. New employees and contractors must be briefed on this policy as part of their onboarding process.

Compliance with this policy may be audited at any time. Evidence of secrets shared via prohibited methods will be treated as a policy violation regardless of intent.

Exceptions¶

Exceptions to this policy may only be granted by the CTO, and must be documented in writing, including the justification, the alternative method approved, the duration of the exception, and any compensating controls applied.

Exceptions must be reviewed at least quarterly and revoked when no longer necessary.

Review¶

This policy will be reviewed at least annually, or following any significant security incident, organisational change, or change to the password.link service. The CTO is responsible for initiating and approving reviews.