Private vs. Public Handbook Policy#

Who is the handbook for?#

The handbook has several audiences:

Current employees of amazee.io who are looking for information on paid-time-off, sick leave, information on time tracking, the company code of conduct, specifics about their role and workstream responsibilities, and other HR or BizOps policies and regulations.
Prospective employees, also referred to as candidates or applicants, who may be interested to find out more about the company in general as well as tips on how best to prepare for interviews and guidance on applying.
The general public, which includes amazee.io clients, prospective and current, who may be interested to know more about the company in general.

There is crossover between the types of content these different audiences may consume in the handbook. For example, both current and prospective employees may be interested to review the code of conduct, and prospective employees and prospective clients may want to learn more about the history of amazee.io.

At the time of writing this policy document, the internal handbook is distinct from the external handbook. The internal handbook can be found on Confluence in the Internal Handbook space, whereas the external handbook can be found on handbook.amazee.io. The external handbook is run on MkDocs with the files living in GitLab.
The goal of this policy document is to bring all handbook content into a single view and for that single view to be open source on the external handbook.amazee.io site. This will require an agreement on what types of information should be public and private.

What is handbook information?#

It is important to note that the type of information that lives in the handbook is different from company documentation more broadly.

Types of documentation at amazee.io#

Generally speaking, company documentation broadly includes:

Technical how-to guides for clients (system configurations, deploying projects, or integrating tools)
Troubleshooting guides for internal teams (diagnosing system bugs, internal tool configuration, resolving internal IT issues)
trust.amazee.io shows certifications, data protection measures, and secure workflows
HR regulations (performance review guidelines, DEI initiatives, vacation policies, employee benefits)
Financial and billing information (processes for managing expense reports, invoicing, and budget approvals; vendor and partner management documentation)
Workflow guides for internal management (project onboarding, resource allocation)
Tool usage documentation (Slack integrations, Jira ticket management)
Technical workflow standards (Git workflows, API documentation)
Codebase documentation (stored in GitLab)

Handbook content#

The type of information that goes into the handbook needs to be understood as meeting the needs of the handbook audiences. These are prospective employees who are looking for recruiting information or doing prep work for interviews; existing employees across all workstreams who are looking for company-wide information on roles, workstreams, links to external resources, HR policies, or BizOps information that may be relevant to the majority of the company.

The handbook acts as a resource for internal employees, prospective employees, and, to a lesser extent, existing and prospective clients who may read the handbook out of general curiosity. As a result, it should contain information like:

Core company values
The history of amazee.io
General operational information (e.g., holidays, meeting schedules)
High-level overviews of processes, linking to more detailed internal or external documentation where relevant.

When information is not considered highly sensitive, all details can be shared in the handbook.

private-vs-public

Open-source by default#

Tip

Default to public unless the content poses a tangible risk to security, compliance, or individual safety. |

As a rule of thumb, all handbook information should be considered open-source (public) by default. This reflects amazee.io's commitment to transparency and the open-source community, as well as taking inspiration from other company handbooks such as GitLab and Trello. Our goal is to make as much information public as possible, ensuring transparency while safeguarding sensitive details.

In some circumstances, it may be necessary to make specific pieces of information private. That does not mean that all information of that type should be made private, only certain portions of information. Examples of this are included in the below policy.

Private or Public? Questions to ask#

When there is uncertainty about the type of information going into the public handbook, here are some questions editors are encouraged to ask themselves to help determine the nature of the content and where it should live. The initial purpose of this question flow is to help editors push past initial discomfort around making information publicly available. It is encouraged to make as much handbook information publicly available as possible.

Understanding highly sensitive or misleading content#

Highly sensitive information is any information that might be problematic if made publicly available through negatively impacting certain individuals, groups, or business operations.
Misleading information is any information that might be misleading or easily misunderstood if read by an unintended reader.

The first question to ask is:

Question

Is there any information here that is highly sensitive or misleading and that we would not want to share publicly?

Warning

If the answer to this is yes (there is sensitive or misleading information we can't share):

Question

What makes this content highly sensitive?

Why would it be problematic to share it publicly?

Who would be affected if this information is made public?

The purpose of this flow of questions is to understand if the content is truly highly sensitive at a critical company level and to push past initial discomfort that may result from making more information publicly available than has been the norm until now.

Understanding risk#

For Private Personal Information, Client data, and Financial data in particular, it is worth asking an additional set of questions.

Client contracts#

Question

Is there information being shared about client contracts that may cause concern or confusion?

Example

On the Understanding our Revenue Structure page currently in the internal handbook in Confluence, there is a line that reads, "There are still legacy and polysite contracts, which are being phased out".

If this is a cause for concern, consider rephrasing to, "Legacy and polysite contracts are currently being phased out as we transition to updated service models. We are committed to ensuring a smooth and transparent process for all affected clients during this transition."

Malicious actors#

Question

Does making this information public create opportunities for malicious actors to misuse private or financial data for identity theft, fraud, or other harmful activities?

Here are some questions to ask to clarify when there is uncertainty. In all situations, the editors need to consider if sharing information increases the risk of social engineering attacks by bad actors and if the degree to which the risk is increased outweighs the usefulness of having the information public.

Question

Could this information help someone pretend to be us (or someone in amazee.io)?

Example

Could it be used to send fake emails, impersonate an employee, or gain unauthorized access? Does this content contain information about amazee.io systems, tools, or internal processes?

For example: Could someone use this to find weaknesses or vulnerabilities (e.g., details about passwords, security setups, or access controls)?

Could this information be used to contact, harass, or manipulate our employees, clients, or customers?

For example: Could someone use publicly available contact details to launch phishing scams or harassment campaigns?

Does this content include financial or account details?

Examples: Bank account numbers, payment instructions, or billing details.

If yes: Could this be misused to commit fraud or theft? Could this information be combined with data from breaches or other public sources to create a bigger security risk?

For example: Publicly shared email addresses combined with passwords exposed in a data breach could allow unauthorized access to accounts. Job titles or team details combined with breached data might make phishing attacks more convincing.

❓Ask: Could sharing this information make it easier for bad actors to exploit previously leaked or publicly available data? Does this information contain or reference sensitive business operations or decisions?

For example: Planned product launches, client lists, or legal matters.

❓Ask: Could making this information public give malicious actors an advantage? Are there any links or attachments that could be risky if shared publicly? For example: Links to internal systems, documents with metadata, or attachments containing sensitive details.

Geopolitical or legal risks#

Because of the global and remote nature of amazee.io, some risks may go beyond simply being concerned about malicious actors through social engineering. Ask these questions to gain clarity, especially when considering sharing information about staff in regions experiencing political unrest (e.g. the country of Georgia).

Example

Could sharing this information put any staff member or partner at personal or legal risk based on their location, government policies, or local regulations? Could it reveal employment details that might conflict with local laws or government policies? Could it identify someone who works remotely from a region where working for certain foreign companies might be problematic? Could it inadvertently disclose a location or affiliation that could make someone a target for political, social, or economic reasons?

Does this content reveal information about individuals or operations in countries with restrictive laws or policies that could pose risks to those involved?

Example: LGBTQ+ staff in countries with anti-LGBTQ+ laws (e.g., UAE, Russia, Uganda), staff in politically sensitive regions.

Does this content reveal too much about remote workers' home locations or private lives?

Example: Posting photos or videos of team calls that include visible backgrounds or personal details.

Follow-up actions for editors#

At this point in the questions, there should be a general understanding of whether this information is too sensitive to share publicly.

Available actions for sensitive information are to:

Redact
Revise
Anonymize
Link to a separate private document in an access-controlled space with or without an overview

Available actions for misleading information are to:

Redact
Revise
Link to a separate private document in an access-controlled space with or without an overview
Add a Disclaimer

Warning

If it is conclusive that yes, there is sensitive or misleading information we can't share:

Question

Can this information be comfortably redacted or revised without compromising the quality and usefulness of the page content for readers?

It will rarely be necessary to make an entire page of content private when there is some sensitive information on the page. For the Company Credit Cards page currently in the Internal Handbook Confluence space, for example, there is the option to further redact the credit card information by removing the owner names and only showing the last two digits of each card rather than the last four digits. Another option is to assign labels to the cards and display those instead of card owners and card numbers.

For example, this is a snippet of information currently displayed on that page:

Owner	Cards	What is the card mainly used for?
John Smith	Mastercard 1234	Licenses and services

This could be altered to something like the following, with the card labels matching the labels in 1Password and a note saying to reach out to certain people for more information or access.

The adjusted information could look something like this

Cards	What is the card mainly used for?
JS Mastercard	Licenses and services

Or this

Cards	What is the card mainly used for?
Licenses Mastercard	Licenses and services

Question

Alternatively, can we split out the sensitive content and link to it in a separate access-controlled space or document?

When information is considered highly sensitive, it can be stored in an access-controlled location like Google Drive and linked to in the handbook.
In the below screenshot example, the guide on submitting talks for events can be public and include a link ("take a look") to additional information in an access-controlled Google Doc.

external-link

Question

Can Private Personal Information be anonymized without compromising the quality and usefulness of the content?

Example: Replace names or specific identifiers with generic terms where appropriate. E.g., instead of using the full name 'Lauren Morris', consider using the role title 'Product Manager'.

Question

Can potentially misleading information be clarified by adding a disclaimer at the top of the page to make it clear to the various audiences (intended readers and readers who might stumble upon it out of curiosity) what the intention of the content is?

Example: "This page is intended as a resource for employees and leads preparing to conduct interviews. The example questions and criteria provided are not exhaustive, prescriptive, or reflective of the specific questions candidates will be asked. For candidates: While you are welcome to review this page, please note that the questions listed here are illustrative and may not appear in interviews. Candidates are encouraged to focus on understanding the role, aligning with our company values, and preparing to discuss their experiences authentically rather than anticipating specific questions."

Common concerns#

Other questions to ask that might help clarify the nature of the handbook content:

Question

What if I'm unsure if something is sensitive?

Answer

Ask yourself these key questions:

Could sharing this information negatively affect someone (e.g., an employee, partner, or client)?
Could it expose the company to risks (e.g., legal, financial, or reputational)?
Could it assist malicious actors (e.g., by exposing internal systems, processes, or personal data)? If you've asked these questions and are still unsure, then check with relevant stakeholders.

Example: A page about company credit cards includes card numbers and the names of employees assigned to those cards.

Guidance: Sensitive information includes card numbers, names, and specific uses (e.g. "John Smith's Mastercard 1234 used for licenses and services").

Remove sensitive details or anonymize them (e.g. "JS Mastercard used for licenses and services")
Link to an access-controlled document in 1Password or Google Drive for detailed information: "For full credit card details, please refer to [this document](secure link)."

Question

What should I do if the content spans both public and private use cases?

Answer

When content has elements that are both public and private: Separate the content into distinct sections: Identify which parts of the content can be safely shared publicly and which need to remain private.

Example: Public-facing information (e.g., a high-level process overview) can be included in the handbook, while sensitive details (e.g., internal workflows or access credentials) should be stored in a restricted location.

Link to private content securely: Instead of including sensitive details directly in the handbook, use a link to access-controlled content stored on a secure platform (e.g., Google Drive, Confluence). Example phrasing: "For detailed internal guidelines, please refer to this document."
Provide context without exposing sensitive details: If possible, rephrase or anonymize private content to keep the public section meaningful while maintaining confidentiality.
Collaborate with stakeholders: If you're unsure how to balance public and private elements, work with the team responsible for the content to identify the best approach.

Example: A page about submitting talks for conferences includes general guidelines and internal event resources.

Guidance:

Public-facing information like submission deadlines and tips for preparing abstracts can go into the handbook. "The deadline for submission is [date]. Ensure your abstract includes the following: A clear problem statement, Relevance to amazee.io's workstreams, Proposed outcomes"
Internal details, such as a draft submission schedule and approval workflows, can be stored privately: "For internal approval workflows, please refer to this [internal document](secure link)."

Tip

Key Takeaway: Default to public content wherever possible, but separate sensitive details into private, secure documents and link to them from the handbook.

Flowchart for decision-making#

Use this flowchart to decide if information is safe to share publicly or needs further review: