--- URL: "/" LLMS_URL: "/index.md" title: "Tuist Handbook" titleTemplate: ":title" --- # Handbook At Tuist, we have learned from the [open-source](https://opensource.org/) community that openness is crucial for creating efficient, asynchronous organizations that thrive in the long term. Inspired by pioneering companies like GitLab, we have embedded openness into the very DNA of our company. This handbook, alongside our [open-source projects](https://github.com/tuist), embodies our commitment to this value. Whether you are part of Tuist or simply interested in how we operate, this handbook offers insight into our company’s inner workings. It is a living document that will evolve as we grow and learn. While the future shape of our company remains uncertain, one thing is clear: **we aspire to be remembered for our legacy of remarkable open-source contributions and the transparency that has guided our decisions and defined our company culture.** > [!IMPORTANT] > The handbook is in its early stages and will evolve over time. If you have any questions or suggestions, please, file an issue in the [handbook repository](https://github.com/tuist/handbook). --- URL: "/community/tuist-digest" LLMS_URL: "/community/tuist-digest.md" title: "Tuist Digest Newsletter" titleTemplate: ":title | Community | Tuist Handbook" description: "Tuist Digest is a newsletter showcasing the most important work happening in Tuist and our vision for the future of app development at scale." --- # Tuist Digest Newsletter Tuist Digest is a newsletter showcasing the most important work happening in Tuist and our vision for the future of app development at scale. Each edition highlights recent developments, upcoming features, and insights into how we're shaping the tools and practices teams need. ## Overview The newsletter is sent at the end of every 6-week cycle via [Loops](https://app.loops.so/), where we have a template specifically created for this purpose. The list of subscribers, templates, and campaigns are all managed using Loops. People can subscribe through the form at [tuist.dev/newsletter](https://tuist.dev/newsletter), and they can unsubscribe at any time by clicking the link at the bottom of the newsletter. --- URL: "/company/6-week-cycles" LLMS_URL: "/company/6-week-cycles.md" title: "6-week cycles" titleTemplate: ":title | Company | Tuist Handbook" mission: "Understand Tuist's 6-week project cycle approach and its benefits" --- # 6-week cycles At Tuist, we shape projects to be executable in 6-week cycles. We believe this timeframe strikes the perfect balance: long enough to deliver meaningful value to teams and developers using Tuist, yet short enough to maintain momentum, focus, and a sense of progress. With our current company size, most projects will typically involve one full-time engineer, while designers work across multiple projects simultaneously, providing their expertise where needed. > [!NOTE] > Software estimation is inherently challenging. Even when we carefully scope work to fit within a 6-week cycle and aim to eliminate unknowns, unforeseen issues may still arise during development. When this happens, we commit to discussing challenges openly and collaboratively to find solutions that work for everyone. ## 2025 Calendar ### 1st Cycle / April 7 - May 18, 2025 - **Week 1:** April 7 - April 13 - **Week 2:** April 14 - April 20 - **Week 3:** April 21 - April 27 - **Week 4:** April 28 - May 4 - **Week 5:** May 5 - May 11 - **Week 6:** May 12 - May 18 - **Cooldown Week:** May 19 - May 25 ### 2nd Cycle / May 26 - July 6, 2025 - **Week 1:** May 26 - June 1 - **Week 2:** June 2 - June 8 - **Week 3:** June 9 - June 15 - **Week 4:** June 16 - June 22 - **Week 5:** June 23 - June 29 - **Week 6:** June 30 - July 6 - **Cooldown Week:** July 7 - July 13 ### 3rd Cycle / July 14 - August 24, 2025 - **Week 1:** July 14 - July 20 - **Week 2:** July 21 - July 27 - **Week 3:** July 28 - August 3 - **Week 4:** August 4 - August 10 - **Week 5:** August 11 - August 17 - **Week 6:** August 18 - August 24 - **Cooldown Week:** August 25 - August 31 ### 4th Cycle / September 1 - October 12, 2025 - **Week 1:** September 1 - September 7 - **Week 2:** September 8 - September 14 - **Week 3:** September 15 - September 21 - **Week 4:** September 22 - September 28 - **Week 5:** September 29 - October 5 - **Week 6:** October 6 - October 12 - **Cooldown Week:** October 13 - October 19 ### 5th Cycle / October 20 - November 30, 2025 - **Week 1:** October 20 - October 26 - **Week 2:** October 27 - November 2 - **Week 3:** November 3 - November 9 - **Week 4:** November 10 - November 16 - **Week 5:** November 17 - November 23 - **Week 6:** November 24 - November 30 - **Cooldown Week:** December 1 - December 7 ### 6th Cycle / December 8 - December 31, 2025 (Shortened Cycle) - **Week 1:** December 8 - December 14 - **Week 2:** December 15 - December 21 - **Week 3:** December 22 - December 31 (extended week to match year-end) ## 2026 Calendar ### 1st Cycle / January 5 - February 15, 2026 - **Week 1:** January 5 - January 11 - **Week 2:** January 12 - January 18 - **Week 3:** January 19 - January 25 - **Week 4:** January 26 - February 1 - **Week 5:** February 2 - February 8 - **Week 6:** February 9 - February 15 - **Cooldown Week:** February 16 - February 22 ### 2nd Cycle / February 23 - April 5, 2026 - **Week 1:** February 23 - March 1 - **Week 2:** March 2 - March 8 - **Week 3:** March 9 - March 15 - **Week 4:** March 16 - March 22 - **Week 5:** March 23 - March 29 - **Week 6:** March 30 - April 5 - **Cooldown Week:** April 6 - April 12 ### 3rd Cycle / April 13 - May 24, 2026 - **Week 1:** April 13 - April 19 - **Week 2:** April 20 - April 26 - **Week 3:** April 27 - May 3 - **Week 4:** May 4 - May 10 - **Week 5:** May 11 - May 17 - **Week 6:** May 18 - May 24 - **Cooldown Week:** May 25 - May 31 ### 4th Cycle / June 1 - July 12, 2026 - **Week 1:** June 1 - June 7 - **Week 2:** June 8 - June 14 - **Week 3:** June 15 - June 21 - **Week 4:** June 22 - June 28 - **Week 5:** June 29 - July 5 - **Week 6:** July 6 - July 12 - **Cooldown Week:** July 13 - July 19 ### 5th Cycle / July 20 - August 30, 2026 - **Week 1:** July 20 - July 26 - **Week 2:** July 27 - August 2 - **Week 3:** August 3 - August 9 - **Week 4:** August 10 - August 16 - **Week 5:** August 17 - August 23 - **Week 6:** August 24 - August 30 - **Cooldown Week:** August 31 - September 6 ### 6th Cycle / September 7 - October 18, 2026 - **Week 1:** September 7 - September 13 - **Week 2:** September 14 - September 20 - **Week 3:** September 21 - September 27 - **Week 4:** September 28 - October 4 - **Week 5:** October 5 - October 11 - **Week 6:** October 12 - October 18 - **Cooldown Week:** October 19 - October 25 ### 7th Cycle / October 26 - December 6, 2026 - **Week 1:** October 26 - November 1 - **Week 2:** November 2 - November 8 - **Week 3:** November 9 - November 15 - **Week 4:** November 16 - November 22 - **Week 5:** November 23 - November 29 - **Week 6:** November 30 - December 6 - **Cooldown Week:** December 7 - December 13 ### 8th Cycle / December 14 - December 31, 2026 (Shortened Cycle) - **Week 1:** December 14 - December 20 - **Week 2:** December 21 - December 27 - **Week 3:** December 28 - December 31 (extended week to match year-end) --- URL: "/company/leadership" LLMS_URL: "/company/leadership.md" title: "Leadership" titleTemplate: ":title | Company | Tuist Handbook" mission: "Learn more about the leadership team at Tuist" --- # Leadership This document contains information about the leadership team at Tuist (roles and people). > [!NOTE] > We are a small companies, so some roles might be held by the same person. Over time, we will update this document to reflect any changes in the leadership team. | Role | Description | Person | | ---- | ---- | ---- | | Chief Executive Officer (CEO) | The CEO is responsible for the overall vision and strategy of the company. | Pedro Piñera | | Chief Technology Officer (CTO) | The CTO is responsible for the technical vision and strategy of the company. | Marek Fort | | Chief Information Officer (CIO) | The CIO is responsible for the company's information technology strategy. | Marek Fořt | | Chief Information Security Officer (CISO) | The CISO is responsible for the company's information security strategy. | Marek Fořt | | Compliance Officer (CO) | The Compliance Officer is responsible for ensuring that the company complies with all relevant laws and regulations. | Pedro Piñera | | IT Manager | The IT Manager is responsible for managing the company's IT infrastructure. | Marek Fořt | --- URL: "/company/mission" LLMS_URL: "/company/mission.md" title: "Mission" titleTemplate: ":title | Company | Tuist Handbook" mission: "Learn more about the mission of Tuist" --- # Mission **To streamline app development through an integrated platform that helps developers build and share high-quality software at unmatched speed and scale.** We believe building apps should be a joyful experience. When developers enjoy their work, they are more productive and create better, more impactful applications. Unfortunately, the current state of app development is far from enjoyable. Developers and teams often find themselves juggling a multitude of tools and data, spending more time building, debugging, and maintaining these tools than focusing on the apps themselves. The web development ecosystem has tackled this challenge effectively with integrated platforms like [Vercel](https://vercel.com). These platforms take a holistic approach to the development process, providing a unified environment where all necessary tools and data converge seamlessly. They guide developers from the initial spark of an idea all the way to production, simplifying and accelerating the journey. We believe app development should—and must—follow a similar path. Developers need a platform that takes them from idea to the app store, combining sensible defaults with the flexibility to adapt to unique needs. From continuous integration and release automation to analytics and testing, everything should be integrated into a cohesive experience. The time has come to revolutionize app development by creating a platform that truly empowers developers to focus on what they do best—building exceptional apps. > [!NOTE] FROM APPLE TO OTHER PLATFORMS > We were born in the Apple ecosystem, but we believe the principles and tools we are developing can be applied to other ecosystems. We aspire to make building at scale delightful for everyone, regardless of the platform they are targeting. ## The app lifecycle The complexity within the ecosystem today stems from the narrow focus of existing solutions. In many cases, proprietary tools either lack APIs or are not open-source, making integration challenging for developers. This not only incurs financial costs but also increases the long-term maintenance burden. We believe that a simpler solution comes from taking a more holistic view of development—considering the entire lifecycle of an app, from the moment a developer envisions a new project to its release on the App Store. Our goal is to understand this entire lifecycle and provide developers with the most effective solutions. By doing so, we ensure that the journey from idea to launch is as seamless as possible. Developers shouldn't have to spend time searching for the right tool or making decisions about their workflow—that's our job, driven by the insights we've gained from the needs of the community. Think of Tuist as something you seamlessly integrate into your repository and then it just works effortlessly. --- URL: "/company/principles" LLMS_URL: "/company/principles.md" title: "Principles" titleTemplate: ":title | Company | Tuist Handbook" mission: "An organization is driven by its people and culture. What follows are the principles of Tuist, which together describe the foundational characteristics of the company." --- # Principles These are the values we hire, work, and part ways by. They define what kind of company Tuist is. Everything else (process, tooling, how we run a week) flows from them. ## Be developer obsessed We obsess over developers the way great product companies obsess over their customers. Our job is to make their teams effective: projects that stay healthy, builds you can trust, tests that tell the truth, releases that don't hurt. Speed is a symptom of that, not the goal. We see customer pain two ways. We dog-food our own tools, so our friction is a signal. And we listen hard to feedback for the pain we can't feel ourselves: different scale, stack, workflow. Either way, we act on it as if we were part of the customer's platform team. In practice: * Every proposal answers: does this make a developer's day shorter, clearer, more reliable, or less painful? * Friction in our own workflow is a product signal, not something to route around. * A bug report sitting untouched for a week is a failure of this principle, not a backlog item. * Complaining about a tool without proposing a fix is not a Tuist-shaped activity. ## Compound with AI Tuist is an AI company. Not because we sprinkle LLMs on features, but because we're building for a world where developers ship alongside agents, and we expect everyone here to already live in that world. AI is a multiplier on work you already do well. The point isn't to make AI the first step in everything. It's to fold it into your workflow so the things you ship are sharper, and there are more of them. A designer who reaches for AI doesn't stop thinking like a designer; they get more of their best work out the door. Same goes for engineering, support, sales, anywhere. That mindset means staying curious about what AI can and can't do, testing the edges, and sharing what you find. Treating AI as a trend to wait out, or as someone else's problem, is not a fit here. In practice: * If a workflow you own hasn't changed in months, that's worth poking at. * Share what's working: a workflow, a prompt, a failed experiment. * Skepticism with evidence is welcome. Skepticism on vibes is not. ## **Ship with taste** AI raises the floor on output. It doesn't raise the ceiling. The ceiling is set by taste, judgment, and care. That's where humans still earn their keep. We expect everyone here to bring great product taste, and to hold a high bar for what ships under our name. Craft shows up in the obvious places (the design system, the CLI's error messages, the docs, the way a page loads) and the unobvious ones (a clear PR description, a well-named function, a support reply that actually helps). It's the difference between something that works and something that feels right. Caring about craft is not a license to over-polish. We ship. But we don't ship work we're not proud of, and we don't hide behind "AI wrote it" when it isn't good enough. In practice: * Before you ship, ask: would I be proud to put my name on this? * Use AI to get to a draft faster, then spend the time you saved on taste: naming, clarity, edge cases, the last 10%. * "It compiles" / "it passes" / "the model produced it" is not the bar. * Polish small things. The error message, the empty state, the typo in the doc. They add up. ## Default to open We publish our handbook, our dashboards, our code, and our roadmap. We work in public because it makes the company better: more feedback, sharper thinking, stronger trust. Openness is load-bearing for us, not a marketing trick. Working in public is also how we operate day to day. Decisions happen in the community forum, in public Slack channels, and in GitHub issues and PRs, not in DMs. Shipping is half the work; writing about how and why we built it is what lets others learn from and build on it. Some things stay private: customer data, performance conversations, unshipped security work, contract negotiations, anything that would put a person or the business at real risk. "It might be embarrassing" or "it's easier" does not clear that bar. In practice: * Public channel, public issue, public PR, unless there's a specific reason not to. * Decisions get written down where the community can find them. * Ship the work, then write about the work. Both count. * If you catch yourself defaulting to private, check the reason. Usually there isn't one. ## Play the long game We are building Tuist for decades, not quarters. The Tuist we want to exist is years away, not weeks. That shapes how we trade off short-term wins against long-term trust, quality, and focus. Playing the long game means saying no to work that would compromise the product, the community's trust, or the team's focus, even when there's short-term pressure to say yes. It means investing in things that pay off slowly: the handbook, the docs, the open source, the relationships. It means not chasing trends we don't believe in. It also means holding our current views with the humility the long game demands. We bring strong opinions, built from real experience and evidence, and we hold them weakly enough to update when the evidence shifts. The failure mode we care about is ego attached to an opinion. It shows up as defending a position after the facts have moved, or as treating disagreement as a personal attack. Over a decade, the people who are right most often are the ones who change their minds most willingly. In practice: * When short-term and long-term disagree, say so out loud before picking. * We don't ship things we'll regret shipping, even if they'd hit a number this quarter. * Bring opinions, especially unpopular ones. Silence is not humility. * If you can't articulate what would change your mind, you don't have a position, you have an attachment. --- URL: "/company/services-and-tools" LLMS_URL: "/company/services-and-tools.md" title: "Services and tools" titleTemplate: ":title | Company | Tuist Handbook" mission: "Learn more about the vision of Tuist" --- # Services and tools This document contains all the third-party services and tools that the company uses to operate, and the reasons why we use them. ## Security ### Vanta We use [Vanta](https://vanta.com) to automate our security compliance. Vanta helps us with SOC 2 compliance, and it provides us with a dashboard that shows the status of our security controls. We chose Vanta because it's a modern and automated solution that helps us save time and resources. ### CanIPhish We use [CanIPhish](https://caniphish.com/) to provide security trainings to employees. We use them because they offer a reasonable and open pricing model. ### 1Password We use [1Password](https://1password.com) to store and manage our passwords securely. 1Password helps us generate strong and unique passwords for each account, and it provides us with a secure vault to store sensitive information. We chose 1Password because it's a trusted and reliable password manager that helps us protect our data. --- URL: "/company/vision" LLMS_URL: "/company/vision.md" title: "Vision" titleTemplate: ":title | Company | Tuist Handbook" mission: "Learn more about the vision of Tuist" --- # Vision **To create a platform where developers seamlessly craft exceptional apps for any platform, accelerating innovation and collaboration.** Our vision is to create a platform where developers can seamlessly craft exceptional software for any platform, from iOS and Android to [React Native](https://reactnative.dev/) and [Flutter](https://flutter.dev/). By removing barriers in the development process, we aim to empower teams to focus on what truly matters: delivering high-quality apps that meets the needs of their users. Our platform is designed to accelerate innovation, enabling developers to iterate faster and bring their ideas to life with unprecedented speed. At the heart of this vision is collaboration—building a community-driven ecosystem where developers come together to learn, share, and contribute toward a brighter future for software development. ## Think different™️ At the core of our company and software is a commitment to [openness](/engineering/open-source.html). We believe **the best ideas can come from anywhere**, and to harness this potential, we foster an environment where everyone can contribute. We embrace openness with curiosity and confidence, not fear. Curiosity also drives our innovation. We are passionate about finding new ways to create value, focusing on making things better, faster, and more enjoyable rather than just balancing costs. **We love innovation and strive to continuously improve.** By sharing our innovations, we empower others to build their own businesses and tools. We welcome competition, believing that the best ideas stem from superior execution, which thrives in an inspiring environment – the very environment we endeavor to create. Moreover, we are strong proponents of [standards](/engineering/standards). We aim to develop solutions that endure over time and give our users the freedom to move their data as they choose. We do not seek to lock anyone into using our platform; instead, we want them to stay because of the exceptional experience they have with Tuist. Lastly, we meet developers where they are by integrating with their existing toolchains and ecosystems, rather than imposing a one-size-fits-all solution. We collaborate with existing ecosystems and open-source projects to enhance their tools and prepare for future scalability. --- URL: "/engineering/cache-infrastructure" LLMS_URL: "/engineering/cache-infrastructure.md" title: "Cache infrastructure" titleTemplate: ":title | Engineering | Tuist Handbook" description: "How Tuist's globally distributed cache nodes are provisioned, deployed, and operated." --- # Cache infrastructure Tuist operates a globally distributed cache that holds build artifacts close to the developers reading them. Latency is the whole point, so the service runs on bare metal in several regions rather than in one place. The fleet is mid-migration between two generations. Kura, a Rust cache mesh, runs on nodes that are ordinary members of our Kubernetes clusters. It is replacing an older Elixir cache service that runs on separately managed hosts. This page describes the current model first, because that is what new work targets, and the fleet being retired second. ## How cache nodes work today A Kura node is a bare-metal box running Ubuntu that has joined one of our Kubernetes clusters as a worker. There is no separate configuration system for it. It gets its configuration the same way every other node does, and Kura itself is scheduled onto it as a workload. That is the substantive change. The old fleet had its own operating system, its own deployment tool, its own secret delivery mechanism, its own reverse proxy, and its own telemetry agent, none of which were the ones the rest of the platform used. A cache host was a different kind of machine that happened to be ours. Now it is the same kind of machine as everything else, which means one way to grant access, one way to deliver secrets, one way to ship telemetry, and one place to look when something is wrong. | Concern | How it is handled | | --- | --- | | Operating system | Ubuntu, installed once during preparation | | Cluster membership | Cluster API, with an operator-minted kubelet identity and secure shell self-join | | Application | Kura, a Rust service, deployed by Helm and reconciled from `KuraInstance` resources | | Storage | Local disk: a metadata store for manifests and replication state, append-only segment files for artifact bodies | | Ingress and certificates | Regional ingress controllers with certificates issued through cert-manager | | Secrets | 1Password, synchronized into the cluster by the External Secrets Operator | | Observability | Grafana Cloud, through the in-cluster telemetry agent that covers every workload | ## Regions | Region | Provider | Location | | --- | --- | --- | | `eu-west` | Scaleway Dedibox | Paris | | `us-east` | OVHcloud | Vint Hill, Virginia | | `us-west` | OVHcloud | Hillsboro, Oregon | | `scw-fr-par-runners` | Scaleway Elastic Metal | Paris | The first three serve customers. `scw-fr-par-runners` is private: it serves the macOS runner fleet's build cache over the private network the Mac minis attach to. Customers do not choose among them. An account is placed in the region its cache traffic comes from, and the placement follows that traffic when it durably moves; what an account states is where its data may live (the storage region setting), which is a compliance boundary rather than a placement. Each account also has a cache hostname without a region in it, so a client that writes the endpoint down keeps working when its cache moves. Each region is one box today. A region's capacity grows by adding boxes, not by splitting an account across them, because an account's cache pods are kept together on a single box. ## How an instance is sized An account's cache instance is bounded on four dimensions: memory, CPU, disk, and egress. Each is a pair, a floor the instance is guaranteed and a ceiling it may reach at peak, and the two are deliberately unequal. Floors decide how many accounts fit on a box, because the scheduler places pods against the sum of their floors and nothing else. Ceilings decide how large a burst an account absorbs before it is shed, and they oversubscribe the box on purpose: headroom above a floor costs nothing until someone uses it. What differs between the dimensions is where the number comes from. | Dimension | Floor | Ceiling | | --- | --- | --- | | Memory | Granted per plan | Granted per plan | | CPU | Measured per instance | Granted per plan | | Disk | Granted per plan, then grown from measured shedding | The same value: the claim is the quota | | Egress | Granted per region, overridable per account | Granted per region | **CPU is the one we measure.** Every other floor is a number we choose in advance, which works when a plan predicts the need. For CPU it does not: instances on the same plan differ from each other by nearly two orders of magnitude, and the two replicas of one instance differ by around ten times, because one serves traffic while the other stands by. No value chosen per plan can see either. So the controller watches each instance's actual usage, keeps a week of it, and asks for what that instance has been observed to need. A flat reservation is what it replaced, and that reservation, not real load, is what once filled a region to the point that new accounts could not be placed in it while the box ran at under a tenth of its capacity. The ceiling is still granted per plan, because how much an account may take is an entitlement while how much it needs is an observation. **Compressible and incompressible dimensions behave differently at the ceiling, and that is why the ceilings are not set alike.** Exceeding a memory ceiling kills the process, so the ceiling has to be far enough above real use that a normal burst never reaches it. CPU is compressible: exceeding the reservation only means being slowed down, and only while the box is contended. But the mechanism that enforces a CPU ceiling is not proportional the way the one for bandwidth is. It hands out a budget every tenth of a second and stops the container dead once that budget is spent, even on a machine that is otherwise idle, so a ceiling set close to real use produces stalls that look like the service being slow rather than being limited. The CPU ceilings are therefore set several times above observed use: high enough to bound a runaway instance, far enough away that ordinary work never meets them. The values themselves live in `server/lib/tuist/kura/regions.ex`, which is where to change them. They are not repeated here, because a number in two places is a number that will disagree with itself. ## Bringing a node into the fleet The controllers never order hardware. A box is ordered by hand, prepared, and then adopted. 1. **Order the box** in the provider console. OVHcloud for the US regions, Dedibox for `eu-west`. 2. **Prepare it.** One task installs Ubuntu, the fleet's secure shell key, and the sudo password, then sets the adoption marker as its final step: ```bash PREP_NAMESPACE=tuist-production mise run baremetal:prep-ovh PREP_NAMESPACE=tuist-production mise run baremetal:prep-dedibox ``` The install runs asynchronously and takes roughly twenty to forty minutes. `PREP_NAMESPACE` selects the environment, which selects both the 1Password vault and the values file the marker is read from. Pass `PREP_SKIP_MARK=1` to stage capacity without releasing it into the pool yet. 3. **Declare the fleet** at the new box count in `infra/helm/tuist/values-managed-.yaml` and deploy. The controller claims the marked box and self-joins it in two to five minutes. Adoption is a claim plus a self-join; the operating system install never runs on this path, which is what keeps it fast. Scaling afterwards is `kubectl scale machinedeployment`. ## Deploying Kura is a mesh, and it is deployed with rolling updates, so nodes running different versions serve traffic side by side during a rollout. Every change has to be safe under that overlap: compatible across one version of skew in both directions, no change to the on-disk or replication formats that an older peer cannot read, and no local optimization that alters the bytes a client receives. The detail lives in `kura/AGENTS.md` and is worth reading before changing anything on the replication path. ## Operating **Access.** Cache nodes are cluster nodes, so they are reached through the same read-only-by-default path as any other workload, with writes going through the just-in-time elevation flow. There is no separate secure shell path for routine work; the fleet key exists for provisioning and recovery. **Secrets.** Held in 1Password and synchronized by the External Secrets Operator. Rotating one means updating the item and letting the operator resynchronize. **Observability.** Metrics, logs, and traces reach Grafana Cloud through the in-cluster agent. Dashboards are version-controlled in `infra/grafana-dashboards/` and synchronized with Grafana Cloud. **Release.** Releasing a box wipes and reinstalls Scaleway Elastic Metal machines. Dedibox and OVHcloud machines are left installed and can be re-adopted. ## The fleet being retired The older cache service is an Elixir application in a container, fronted by nginx, running on hosts managed with NixOS and deployed with Colmena and Kamal. Its configuration lives in `cache/platform/` and its host list in `cache/config/deploy*.yml`. It is still serving production traffic across roughly ten regions while Kura regions come up beside it. It is being retired region by region rather than in one cutover, and nothing new should be built on it. If you need the provisioning and deployment detail for a host that is still in service, `cache/platform/` and `cache/AGENTS.md` have it. NixOS applies only to that fleet. New cache nodes do not use it. ## Related - `kura/AGENTS.md` and `kura/docs/architecture.md` for the mesh itself - `infra/cluster-api-provider-tuist/AGENTS.md` for the machine kinds and the adoption flow - `infra/AGENTS.md` for how the clusters fit together --- URL: "/engineering/open-source" LLMS_URL: "/engineering/open-source.md" title: "Open Source" titleTemplate: ":title | Engineering | Tuist Handbook" description: "Open source is a powerful force that drives innovation and collaboration. At Tuist, we are committed to building a world-class open source productivity platform for app developers." --- # Open Soure Throughout history, [open source](https://en.wikipedia.org/wiki/Open_source) has demonstrated its incredible power in creating enduring software. It unites a diverse community of dedicated crafters, driven by a passion to make a meaningful impact on the world. **The value of open source often transcends financial metrics**, though it has proven to be a catalyst for thriving business markets. For instance, [Linux](https://en.wikipedia.org/wiki/Open_source) became a cornerstone of the modern Internet, showcasing the profound influence of open source. Companies like [Apple](https://opensource.apple.com/) and [Microsoft](https://opensource.microsoft.com/) were slow to recognize this, and many still hesitate, fearing the exposure of their innovations to the public. At our core, **we believe open source is unparalleled, and it is deeply embedded in our DNA.** Rather than fearing it, we embrace open source with curiosity and a fervent desire to collaborate with fellow innovators. Our mission is to build new infrastructure that unlocks fresh market opportunities. We don't see ourselves in competition with others; instead, we innovate and share our creations, encouraging others to innovate within our space as well. This approach fosters a richer world where new ideas and markets can flourish. We aim to inspire others to join us on this path. With this vision, we are committed to making Tuist entirely open source, following the examples of [Supabase](https://supabase.com/) and [GitLab](https://gitlab.com). Initially, we closed parts of our code out of fear of being outcompeted by VC-funded entities. However, now that our business is secure, we are reversing that decision. Our goal is to **develop a world-class open source productivity platform for app developers.** ## Best practices Open source software has the potential to drive innovation and collaboration, but it must be approached thoughtfully. Here are some guidelines to ensure that open sourcing software is both effective and meaningful: - Avoid open sourcing software that is not actively maintained merely for marketing purposes. Without proper maintenance, the software cannot serve its community effectively. The only exception to this rule is software that represents examples or experiments. - Do not open source software that lacks standalone value or fails to attract interest for further development. Ensuring that the software has a clear, independent utility is crucial for community engagement and contribution. By following these best practices, we can foster a more robust and sustainable open source ecosystem. ## Licenses Choosing the right license is crucial to maintaining financial sustainability in open source. Here are our guidelines for selecting licenses: - For command line tools, libraries, or packages intended for others to extend and build upon, we will use the permissive [MIT license](https://opensource.org/license/mit). Examples include the [Tuist CLI](https://github.com/tuist/tuist) and the [XcodeProj](https://github.com/tuist/xcodeproj) package. - For projects that are integral to Tuist’s financial sustainability, we will release them under the [AGPL3 license](https://www.gnu.org/licenses/agpl-3.0.en.html), with some enterprise-specific features available under a commercial license. This ensures the project remains open while securing necessary funding for ongoing development. If there is any uncertainty about a project's business criticality, we encourage discussion in the #oss channel. > [!NOTE] OSI LICENSES > To ease understanding and compliance, we will use licenses approved by the [Open Source Initiative](https://opensource.org/). We will also ensure that all dependencies are compatible with our chosen licenses. ## Nice citizens of the open source world When selecting services to meet various business needs, we should prioritize open source solutions and actively contribute to their growth. This can be achieved by reporting ideas and bugs, fixing issues, implementing new features, and supporting maintainers or companies through donations or paid hosted services. To ensure that open source projects thrive, we must be good citizens and support others who share our commitment to open source. --- URL: "/engineering/scheduled-maintenance" LLMS_URL: "/engineering/scheduled-maintenance.md" title: "Scheduled maintenance" titleTemplate: ":title | Engineering | Tuist Handbook" description: "This document outlines our company's approach to communicating scheduled maintenance activities to users." --- ## Scheduled Maintenance Guidelines ### Overview This document outlines our company's approach to communicating scheduled maintenance activities to users. Following these guidelines ensures transparent and timely communication about system maintenance and potential service interruptions. | Category | Expected Impact | First Notice | | -------- | ---------------------------------- | ------------ | | Minor | No expected downtime, minimal risk | 24 hours | | Standard | Limited service interruption | 3 days | | Major | Significant service interruption | 7 days | ### Scheduling For activities that we expect to cause a service interruption (standard or major), we aim to place the maintenance window to not overlap with business hours of our customers. This ensures that the interruption has minimal impact on the user experience. Given the distributed nature of our customer base, planning should take into account all time zones of the affected users. ### Messaging All maintenance announcements, regardless of category, should include: - Start date and time (including timezone) - Expected duration - Components affected - Expected user impact - Link to status page for updates ### Maintenance Categories The following categories should be considered as guidelines for scheduling maintenance activities. Depending on the activities and associated risks, the category may be adjusted accordingly. #### Minor Maintenance **Expected Impact**: No expected downtime, minimal risk Minor maintenance is a low-risk maintenance activity that we do not expect to cause a service interruption. We communicate these activities for transparency and for risk management. ##### Communication Timeline - First notice: 24 hours before - Reminder: 1 hour before ##### Communication Channels - Status page - Slack announcement - Community forum post (optional) #### Standard Maintenance **Expected Impact**: Limited service interruption **Duration**: 5-60 minutes Standard maintenance is an activity that we expect to cause a limited service interruption, meaning that at least part of the service is unavailable for a short period of time. ##### Communication Timeline - First notice: 3 days before - Reminders: - 24 hours before - 1 hour before ##### Communication Channels - Status page - Slack announcement - Community forum post #### Major Maintenance **Expected Impact**: Significant service interruption **Duration**: 1 hour or longer A major maintenance activity is an activity that we expect to cause a significant service interruption, meaning that part or the entirety of the service is unavailable for an extended period of time. ##### Communication Timeline - First notice: 7 days before - Reminders: - 3 days before - 24 hours before - 1 hour before ##### Communication Channels - Status page - Slack announcement - Social media announcement - Community forum post - Email notification for all affected users --- URL: "/engineering/server/error-handling" LLMS_URL: "/engineering/server/error-handling.md" title: "Error handling" titleTemplate: ":title | Server | Engineering | Tuist Handbook" description: "Our approach to error handling using Elixir on the server." --- # Error handling Matching Elixir conventions, Tuist server functions should return success and errors as values in form of `{:ok, result}` and `{:error, reason}` tuples. In order for us to leverage automatic error handling, we follow a standardized error format that is used across both domain and interface logic. ## Error format 1. Any successful function execution should return `{:ok, result}`, where `result` can be any value. 2. Any error where the function execution is not successful should return `{:error, reason}`, where `reason` is a string describing the error. For generic errors, the `reason` should be an atom describing the error code: 1. `:unauthenticated` - There is no authenticated user. 2. `:unauthorized` - The authenticated user is not authorized to perform the requested action. 3. `:not_found` - The requested resource was not found. > [!NOTE] > In our controller error handling, `:unauthenticated` maps to HTTP error `401` and `:unauthorized` maps to HTTP error `403`. This does not > match the HTTP status code name, but matches the cause of the error more closely. For input errors, the preference is to return an `%Ecto.Changeset{}` containing the error messages pertaining to the related input fields. For all other errors, `reason` should be a string describing the error. These error formats allow us to handle errors in a consistent way across domain logic and controllers, making it possible to simply return the errors inside our controller actions and have automatic formatting and status code handling. ## Controller example ```elixir with {:ok, account} <- get_account(handle), # returns {:ok, account} or {:error, :not_found} :ok <- can(conn.assigns.current_user, :update, account, :organization), # returns :ok or {:error, :unauthorized} {:ok, account} <- Accounts.update_account(account, params) do # returns {:ok, account} or {:error, changeset} conn |> put_status(:ok) |> json(%{id: account.id, handle: account.name}) end ``` Since the `with` clause returns all non-matching values as-is, the error paths will be passed onto the controller which will handle them generically. --- URL: "/engineering/standard-practices" LLMS_URL: "/engineering/standard-practices.md" title: "Standard practices" titleTemplate: ":title | Engineering | Tuist Handbook" description: "Standard practices are the set of guidelines that Tuist engineers follow to ensure that the codebase is consistent, maintainable, and scalable." --- # Standard practices ## Trunk-based development Tuist repositories follow [trunk-based development]() with `main` as the default branch, requiring at least two approvals for pull requests and CI to pass before merging. CI checks should include thorough testing, linting, and code formatting that ensures code style consistency throughout the organization. --- URL: "/engineering/standards" LLMS_URL: "/engineering/standards.md" title: "Standards" titleTemplate: ":title | Engineering | Tuist Handbook" description: "Learn about Tuist's stance on adopting and embracing standards over proprietary abstractions and tools." --- # Standards To create a platform that stands the test of time, we must prioritize certain principles. One of the most important is choosing standards over proprietary abstractions and tools. This principle should guide not only [our technology choices](/engineering/technologies) but also our product design. ## The Power of Standards Standards are widely adopted and maintained by a community. For example, consider the web platform standards like [HTML](https://en.wikipedia.org/wiki/HTML), [CSS](https://en.wikipedia.org/wiki/css), and [JavaScript](https://en.wikipedia.org/wiki/JavaScript). These standards are designed to be backward compatible and evolve without breaking existing implementations. This stability allows us to focus on building features that matter to our users rather than constantly updating to maintain compatibility with proprietary tools. Standards also enable [portability](https://en.wikipedia.org/wiki/Software_portability), allowing users to move freely across tools and platforms without being locked in. If our users choose to stay with Tuist, it should be because they love the product, not because they are trapped by the technology. While it is rare that a standard will not meet our needs, in such cases, we should actively contribute to the standardization process to ensure it evolves to address those needs. ## Embracing Long-Term Solutions As developers, it can be tempting to adopt the latest tools that promise to solve all our problems. While these tools may offer short-term benefits like increased productivity or a better developer experience, we must remember that Tuist is a long-term, infinite game. Eventually, standards will catch up, and if they don’t, we have the opportunity to contribute to their development. For example, [OpenAPI Spec](https://swagger.io/specification/) and its tooling have evolved to compete with [GraphQL](https://graphql.org/), demonstrating how standards can advance over time. Sometimes, peeling back the layers of proprietary tools and abstractions reveals that the core functionality has improved significantly. In such cases, the additional layers may no longer be necessary. For instance, it’s perfectly acceptable to have a [#nobuild setup](https://world.hey.com/dhh/you-can-t-get-faster-than-no-build-7a44131c) for a web project, despite common misconceptions. By adhering to these principles, we ensure that our platform remains robust, adaptable, and user-focused, standing the test of time in an ever-evolving technological landscape. --- URL: "/engineering/technologies" LLMS_URL: "/engineering/technologies.md" title: "Technologies" titleTemplate: ":title | Engineering | Tuist Handbook" description: "This document includes a list of technologies that are approved for use in Tuist projects along with the rationale behind each decision." --- # Technologies When deciding a technology to use in a new project, we try to be pragmatic ensuring we prevent technology fragmentation. This document includes a list of technologies that are approved for use in Tuist projects along with the rationale behind each decision. If you believe a technology should be added or removed from this list, please [open a pull request](https://github.com/tuist/handbook/compare). ## How we choose technologies One of our core principles in technology selection is adhering to [standards](/engineering/standards) that strike a perfect balance between simplicity and power. Many **widely adopted technologies hide underlying complexities resulting from poor foundational design.** This hidden complexity eventually surfaces, making software maintenance and evolution more challenging. A prime example of achieving simplicity through robust design is found in [Erlang](https://en.wikipedia.org/wiki/Erlang_(programming_language)) and [Elixir](https://en.wikipedia.org/wiki/Elixir_(programming_language)). These technologies provide primitives that effectively model the real world, eliminating the need for endless layers of abstractions that are common in other ecosystems. We are also mindful of cutting-edge technologies. While they often bring innovation and spark valuable debates, their premature adoption can divert us from our primary mission: building a world-class productivity platform for app developers. By focusing on well-designed, standard-based technologies, we ensure our platform remains robust, maintainable, and aligned with our long-term goals. ## Programming languages ### Swift Tuist started as a [Swift](https://www.swift.org/)-based CLI tool. We chose Swift because it was important that the technology we used to build our tool was the same as the technology we were building the tool for. That way, **developers would be more likely to contribute to the project.** If you are building a command line interface or an application for any of the Apple platforms, it must be written in Swift, a language the organization is very familiar with. > [!TIP] MULTI-PLATFORM CLI TOOLS > If you come across a situation where you need to build a multi-platform CLI tool, we might accept the usage of other languages like [Rust](https://www.rust-lang.org/), whose standard library has been better designed and battle-tested to work across different platforms. Note that despite we like Swift, and we try to push it as much as possible, we acknowledge domains where Swift is not the best fit, and choose other technologies accordingly. ### Elixir [Elixir](https://elixir-lang.org/) is our go-to language for **building backend services and apps.** We chose Elixir because it is a functional language that runs on the [Erlang VM](https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)), which is known for its fault-tolerance and scalability. Elixir is also a language that is easy to learn and has a great community. It's common for organizations and developers to see Elixir as a risk since its ecosystem is not as large and diverse as others (e.g. JavaScript). However, it has something unique that often goes unnoticed. Its approach to programming and the battle-tested runtime, Erlang, **make it extremely easy and cheap to scale, both development and also production-runnin applications.** While Erlang and Elixir can go a very long way with few resources (e.g. engineers, infrastructure complexity), other runtimes require earlier "throwing money at the problem" or "relying on costly external services that abstract the complexity away". > [!NOTE] A NOTE ON LEARNING ELIXIR > Since it's not as popular as other languages, it might be harder to find Elixir developers. However, our aim is to have a team that is capable of learning new technologies and languages. We believe that the benefits of using Elixir outweigh the costs of learning it. ## Standards ### OpenAPI [OpenAPI](https://swagger.io/specification/) is a standard for defining APIs. We use it to define the APIs of our services. It allows us to generate documentation, client SDKs, and server stubs, which makes it easier to maintain and evolve our services. > [!NOTE] GRAPHQL > Although GraphQL has been gaining popularity, we have decided to stick with REST APIs for now. We believe that REST APIs are more straightforward and easier to understand for developers who are not familiar with GraphQL. Moreover, we don't have the need for giving clients the flexibility to request only the data they need, which is one of the main benefits of GraphQL. So we'd end up having to deal with [their challenges](https://www.magiroux.com/eight-years-of-graphql) early, distracting us from our primary mission. ## Technologies ### Scalar We generate documentation for [OpenAPI](#openapi) using [Scalar](https://github.com/scalar/scalar). It's open-source, and it allows us to generate beautiful documentation websites from OpenAPI specifications. If you are serving it from an [Elixir](#elixir) project, you can use our [scalar_plug](https://github.com/tuist/scalar_plug) library to serve the documentation from your Phoenix application. ## Project types ### Statically-generated documentation websites Our go-to framework for building statically-generated documentation websites is [VitePress](https://vitepress.dev/). It's maintained by the minds behind [Vue.js](https://vuejs.org/) and [Vite](https://vitejs.dev/), and can generate beautiful documentation website out of the box with all the features we need, including internationalization, search, and more. ### Statically-generated websites When building statically-generated websites, we use [11ty](https://www.11ty.dev/). Unlike other frameworks whose development is is heavily reliant on external investment or that build on layers of abstractions, making them not future-proof, 11ty is a simple, flexible, and powerful static site generator that embraces the platform rather than abstracting it. --- URL: "/marketing/case-studies" LLMS_URL: "/marketing/case-studies.md" title: "Case studies" titleTemplate: ":title | Marketing | Tuist Handbook" description: "This document provides guidelines for creating case studies that showcase the impact of Tuist on organizations' projects." --- # Case studies Case studies are a useful tool to **celebrate the success of Tuist users and showcase the impact of Tuist on their projects.** They provide a real-world perspective on how Tuist has helped teams overcome challenges and achieve their goals. It helps future customers understand the value of Tuist through the lenses of existing organizations, giving Tuist credibility and trustworthiness. Therefore, we should suggest organizations to share their stories with us, so we can create case studies that can be shared on our website, blog, and social media channels. Note that some might not feel comfortable sharing their stories publicly, so we should respect their privacy and only publish case studies with their explicit consent. Once an organization has agreed to share their story, you can use the following template to create a case study: - **Name:** The name of the organization. - **URL:** A link to the organization's website. - **Solutions:** The features of Tuist that the organization used to solve their challenges. - **The problem/challenge:** One pragraph describing the challenges the organization faced. - **Why Tuist?:** One paragraph explaining why the organization chose Tuist. You can use bullet points to list the various reasons. - **The results:** A list of advantages and improvements that the organization experienced after adopting Tuist. Each one should be a title followed by a paragraph describing the impact. You can use [this Supabase case study](https://supabase.com/customers/voypost) as a reference. --- URL: "/marketing/guidelines" LLMS_URL: "/marketing/guidelines.md" title: "Guidelines" titleTemplate: ":title | Marketing | Tuist Handbook" description: "This document provides guidelines for doing marketing for Tuist." --- # Guidelines Tuist’s target audience is developers, a group for whom many traditional marketing strategies may not resonate. We believe that effective marketing requires first understanding the developer mindset. ## Developers' mindset Developers sit at the crossroads of creativity and logic. They’re driven by a desire to peek "under the hood" of systems, favoring transparency and openness over opaque solutions. Traditional sales and marketing tactics often fall flat with them—such approaches can feel intrusive or even off-putting. Trust, for developers, is built through deep understanding. They can quickly discern whether content is thoughtful and well-crafted or merely attention-seeking fluff. They value extensibility, always anticipating edge cases where a tool might fall short. Vendor lock-in is a red flag they spot from a mile away, pushing them away from rigid ecosystems and toward open-source solutions. These collaborative, customizable, and forkable options align with their need for flexibility and control. Collaboration is in their DNA. Developers thrive in open movements and gravitate toward community-driven efforts. They recognize that financial sustainability is necessary for projects to endure, but they bristle when profit feels like the primary motive. Some developers harbor entrepreneurial ambitions, identifying as "indie" developers. For them, software is less a passion project and more a practical tool. They think in economic terms, treating technology as a means to an end and approaching it with a pragmatic, sometimes disposable mindset. ## Our community is our best marketing A passionate, loyal community that feels part of a movement is a company’s most powerful marketing asset. Pair that with an ecosystem rooted in open source, and you create something unstoppable. Tuist began with open source principles, and we’re now doubling down—strengthening our commitment to foster a collaborative, innovative, and thriving ecosystem. To make this happen, we invest in people. We support those who show up, offering guidance as they take their first steps using or contributing to Tuist. This approach is slow and deliberate, but it’s sustainable—unlike fast, capital-driven marketing that burns bright and fades fast. We want Tuist to be remembered for its values, mission, and community, not for saturating every conference, newsletter, blog, or social media feed. Good things take time, and this kind of marketing is no exception. We see it as planting seeds—nurturing them patiently as they grow into something lasting. Our focus doesn’t stop at attracting people to Tuist; we want them to stay and build with us. Right now, most stick around because they use or contribute to Tuist. But what if they could build on Tuist? We’re exploring creative ways to make that possible—through extensibility, like developing API clients or designing a platform that invites extensions. By empowering people to shape Tuist, we turn users into creators, deepening their connection to our mission. ## Slow, deep, and accessible content Algorithms prioritize fresh, quick, and eye-catching content—a trend AI is amplifying. It’s easy to fall into the trap of spinning like a hamster on a wheel, churning out clickbait for platforms that hoard the value. Today, your meme might spread like wildfire; tomorrow, it’s all anyone recalls—but no one engages with your work. Amid the overwhelming noise, people are weary. They cherish stumbling upon a signal—something substantial in an ocean of chaos. We aim to be that signal: a deliberate counterpoint to a world obsessed with speed. Accessibility is the foundation. That means open web platforms. Let’s choose [the Community Forum](https://community.tuist.dev) over [Slack](https://slack.com) for rich, searchable discussions—spaces where deep ideas can breathe and be discovered. Our videos are published on our [PeerTube](https://joinpeertube.org/) instance at [videos.tuist.dev](https://videos.tuist.dev). We own the content. Let’s craft content on our blog and share it on open networks like [Bluesky](https://bsky.app/profile/tuist.dev) or [Mastodon](https://fosstodon.org/@tuist), where we control our voice, not closed silos. LinkedIn’s an option, though its vibe feels off. SEO isn’t complicated—here’s how we approach it: - Write on topics people care about, but only if we can dive deep with meaning—no shallow fluff. Imagine advising a friend. - Balance the mix: ⅓ SEO-focused articles, ⅓ tutorials, ⅓ freeform pieces. - Focus on titles, keywords, and dwell time—Google tracks engagement, not nuance. - Link to relevant resources and keep content fresh—Google rewards updates. Our team should explore passions that intersect with what our audience expects from us. Writing about Tuist is fine, but it can’t be the sole focus—otherwise, we’re only visible to those already seeking us out. Broaden the lens to invite new readers who stay for the insight. ## On paid advertising Paid marketing can feel forced to developers when it’s too broad or relentless. A mention at a conference, in a newsletter, or after a quiet stretch? That’s fine—it’s subtle. But plaster your name everywhere, and developers will sense you’re buying their attention, even encroaching on their time. We’ll sponsor selectively—events, newsletters, blogs—focusing on emerging voices and initiatives just finding their footing. These are the people and projects we want to lift, boosting their confidence and fueling their growth. Finding them takes effort; they’re often quiet, shying from the spotlight. But they’re our audience. The strongest voices lie dormant, waiting for a spark—we aim to be that spark. Our sponsorships must spotlight the problem, tie it to our solution, and share our vision for the space—Tuist’s role included. Values matter too. We’re not just another developer tool; we’re one that champions open source as a win for all. Money is our means to amplify this, not our endgame. Every sponsorship should echo that ethos. ## Show your true colors We’ve built a team brimming with passion for this space—let that shine in everything you publish. Passion is contagious; when you reveal what drives you, it sparks curiosity about your work and Tuist. It’s human nature to connect with authenticity—traditional marketing feels forced unless it’s woven with storytelling. Communicate with respect and joy. Center your focus on the problem and the solution, steering clear of toxic traps like comparisons or schadenfreude over other tools. Highlight Tuist’s strengths, and if asked to compare, offer honest pros and cons if you’re informed—or simply admit you haven’t explored the alternatives. Share your take on the problem space: how you see it evolving and where Tuist fits in. Offer bite-sized, creative ideas for tackling challenges in fresh ways. People crave originality, and at Tuist, we’re full of it—let’s not keep it to ourselves. ## Useful resources - [Ideas for blog content](https://community.tuist.dev/t/ideas-for-blog-content/472) - [Dev tool marketing for early-stage startups – what we’ve learned](https://posthog.com/founders/dev-marketing-for-startups) --- URL: "/people/benefits" LLMS_URL: "/people/benefits.md" title: "Benefits" titleTemplate: ":title | People | Tuist Handbook" description: "Learn about the benefits and perks of working at Tuist." --- # Benefits At many technology companies, perks are offered on top of salaries—free lunches, gym memberships, or wellness stipends. While these benefits can be appealing, they often create an emotional dependency between employees and the company. This isn’t something we encourage at Tuist. Instead, we believe in **paying people fairly** and **giving them the freedom** to decide how to spend their compensation in ways that best support their needs and lifestyle. ## Flexible approach to compensation We ensure that everyone at Tuist receives a **competitive salary** based on their experience level and location. Rather than predefining perks for you, we give you the autonomy to decide. Want to use it for a gym membership? That’s great! Would you rather invest in learning a new language? Perfect! This approach ensures that your compensation is truly yours and that you’re not tied to perks chosen by the company. ## Investing in the tools & support you need ### 💻 The right equipment from day one We want you to work with the best tools available. Every team member receives a **high-end MacBook** to ensure a smooth and efficient workflow. ### 🌍 An open & transparent culture Tuist is designed to be an **open company**. That means you’ll have insight into how decisions are made and the opportunity to participate in shaping our direction. We believe that transparency fosters trust and collaboration, and we actively encourage contributions from everyone on the team. ### 🏡 Remote-first, with flexibility You have complete control over where you work. Whether you prefer working from home, in a co-working space, or while traveling, the choice is yours. If you're based in Berlin, we provide a desk in a shared workspace, giving you the option to collaborate in person with teammates when needed. We currently hire only in Germany and can assist with relocation and visa processes if required. In the future, we may expand to hiring globally through Employer of Record (EoR) platforms if we find exceptional candidates. ### ⏳ Work on your schedule We understand that productivity looks different for everyone. At Tuist, you have **full flexibility** to structure your work hours in a way that allows you to do your best work. We rely on **asynchronous communication** to keep projects moving forward without requiring everyone to be online at the same time. ## Growing & learning together We believe in **continuous learning and professional development.** To support that, we provide: ### 📚 A €1,000 annual learning budget This can be used for courses, books, certifications, or attending industry events. If you're traveling for a conference, we'll cover transport, tickets, and accommodation—as long as it stays within the budget. If you are speaking or giving a workshop at a conference, we'd cover the costs that are not covered by the organizers. A maximum of 5 days per year can be used as working time for attending conferences/events. ### 🛠️ A €500 one-time hardware budget To help you set up your ideal work environment, we provide a one-time budget that you can use for anything from a comfortable office chair to additional tech accessories. ### 👥 An annual team retreat While we’re a remote-first company, we recognize the value of in-person connections. That’s why we organize an annual retreat where the entire team gets together for a week. Each year, we choose a different location, giving everyone a chance to step away from daily work, collaborate, and build stronger relationships—it’s one of the highlights of the year! In addition to the retreat, we also come together for hack events. These focused gatherings allow us to brainstorm, prototype, and work intensively on innovative ideas while enjoying the energy of in-person teamwork. Whether it's tackling big challenges or experimenting with new concepts, these events bring a fresh perspective and strengthen our collaboration. --- At Tuist, our philosophy is simple: **We trust you to make the best decisions for yourself.** Rather than imposing perks, rigid schedules, or unnecessary rules, we focus on **empowering you with the flexibility, tools, and support needed to do your best work.** We believe that when people feel trusted, valued, and supported, great things happen. --- URL: "/people/code-of-conduct" LLMS_URL: "/people/code-of-conduct.md" title: "Code of Conduct" titleTemplate: ":title | People | Tuist Handbook" description: "The code of conduct for the Tuist GmbH staff." --- # Code of Conduct - **Policy Owner:** Pedro Piñera Buendía - **Effective Date:** 7th January, 2025 ## Purpose The primary goal of Tuist GmbH’s Code of Conduct is to foster inclusive, collaborative, and safe working conditions for all Tuist GmbH staff. As such, Tuist GmbH is committed to providing a friendly, safe, and welcoming environment for all staff, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status, or religion (or lack thereof). This Code of Conduct outlines our expectations for all Tuist GmbH staff, as well as the consequences for unacceptable behavior. It also reflects our commitment to conducting business in compliance with applicable laws, ensuring fairness, and protecting confidential information. ## Scope The Code of Conduct applies to all Tuist GmbH staff. This includes full-time, part-time, and contractor staff employed at every seniority level. The Code of Conduct is to be upheld during all professional functions and events, including but not limited to business hours at the Tuist GmbH office, during Tuist GmbH-related extracurricular activities and events, while attending conferences and other professional events on behalf of Tuist GmbH, and while working remotely and communicating on Tuist GmbH resources with other staff. We expect all Tuist GmbH staff to abide by this Code of Conduct in all business matters — online and in-person — as well as in all one-on-one communications with customers and staff pertaining to Tuist GmbH business. This Code of Conduct also applies to unacceptable behavior occurring outside the scope of business activities when such behavior has the potential to adversely affect the safety and well-being of Tuist GmbH staff and clients. ## Defined Principles, Values, and Standards Tuist GmbH is committed to: - Acting with integrity and professionalism in all interactions. - Promoting a culture of inclusion, collaboration, and respect. - Complying with all applicable laws and regulations. - Ensuring fairness in all business dealings. - Protecting confidential information and respecting intellectual property rights. ## Culture and Citizenship A supplemental goal of this Code of Conduct is to increase open citizenship by encouraging participants to recognize the relationships between our actions and their effects within Tuist GmbH culture. **Be welcoming.** We strive to be a company that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability. **Be considerate.** Your work at Tuist GmbH will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. **Be respectful.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a company where people feel uncomfortable or threatened is neither productive nor pleasant. Tuist GmbH staff should always be respectful when dealing with other personnel as well as with people outside of Tuist GmbH employment. ## Legal Compliance and Anti-Corruption All Tuist GmbH staff are expected to: - Conduct business in full compliance with all applicable local, national, and international laws and regulations. - Avoid and reject facilitating payments or any form of corruption, bribery, or unethical behavior in all business dealings. - Report any requests or demands for improper payments immediately to Tuist GmbH leadership. ## Confidentiality and Conflicts of Interest - Tuist GmbH staff must protect confidential information, both company and customer-related, and only share it as necessary for business purposes or as required by law. - Avoid conflicts of interest that may interfere with the objectivity of decision-making in Tuist GmbH’s business dealings. Disclose any potential conflicts of interest to leadership promptly. ## Acceptable and Expected Behavior The following behaviors are expected and requested of all Tuist GmbH staff: - Participate in an authentic and active way. In doing so, you contribute to the health and longevity of Tuist GmbH. - Exercise consideration and respect in your speech and actions at all times. - Attempt collaboration before conflict. - Refrain from demeaning, discriminatory, or harassing behavior and speech. - Be mindful of your surroundings and of your fellow participants. Alert Tuist GmbH leaders if you notice a dangerous situation, someone in distress, or violations of this Code of Conduct, even if they seem inconsequential. - Remember that Tuist GmbH events may be shared with members of the public and Tuist GmbH customers; please be respectful to all patrons of these locations at all times. ## Unacceptable Behavior The following behaviors are considered harassment and are unacceptable within our community: - Violence, threats of violence, or violent language directed against another person. - Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language. - Posting or displaying sexually explicit or violent material. - Posting or threatening to post other people’s personally identifying information ("doxing"). - Personal insults, particularly those related to gender, sexual orientation, race, religion, or disability. - Inappropriate photography or recording. - Inappropriate physical contact. You should have someone’s consent before touching them in any manner. - Unwelcome sexual attention. This includes sexualized comments or jokes; inappropriate touching, groping, and unwelcome sexual advances. - Deliberate intimidation, stalking, or following (online or in person). - Advocating for, or encouraging, any of the above behavior. - Repeated harassment of others. In general, if someone asks you to stop, then stop. - Other conduct which could reasonably be considered inappropriate in a professional setting. ## Weapons Policy No weapons will be allowed at Tuist GmbH events, office locations, or in other spaces covered by the scope of this Code of Conduct. Weapons include but are not limited to guns, explosives (including fireworks), and large knives such as those used for hunting or display, as well as any other item used for the purpose of causing injury or harm to others. Anyone seen in possession of one of these items will be asked to leave immediately and will be subject to punitive action up to and including termination and involvement of law enforcement authorities. Tuist GmbH staff are further expected to comply with all state and local laws on this matter. ## Consequences of Non-Compliance Unacceptable behavior from any Tuist GmbH staff, including those with decision-making authority, will not be tolerated. Anyone asked to stop unacceptable behavior is expected to comply immediately. If a staff member engages in unacceptable behavior, Tuist GmbH leadership may take any action deemed appropriate, up to and including suspension or termination. This includes violations of confidentiality, conflicts of interest, or legal compliance requirements. ## Employee Acknowledgment and Acceptance All Tuist GmbH staff are required to: - Confirm in writing that they have read, understood, and will comply with the Code of Conduct. - Reaffirm their acknowledgment on an annual basis or whenever significant updates are made to this document. ## Reporting Violations If you are subject to or witness unacceptable behavior, or have any other concerns, please notify an appropriate member of Tuist GmbH leadership as soon as possible. It is a violation of this policy to retaliate against any person making a complaint of unacceptable behavior or against any person participating in the investigation of (including testifying as a witness to) any such allegation. Any retaliation or intimidation may be subject to punitive action up to and including termination. ## Disciplinary Action Employees who violate this policy may face disciplinary consequences in proportion to their violation. Tuist GmbH management will determine how serious an employee’s offense is and take the appropriate action. ## Version History The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/people/how-we-work" LLMS_URL: "/people/how-we-work.md" title: "How we work" titleTemplate: ":title | People | Tuist Handbook" description: "Our approach to working together." --- # How we work ## Remote As a remote-first company, we meticulously design our processes and tools to optimize remote work. Our commitment to excellence leads us to seek out and hire top talent globally, constrained only by legal considerations, not geographical boundaries. We entrust you with the responsibility of crafting your ideal work environment and determining your most productive schedule. Our faith in your judgment is unwavering; we believe you'll make choices that best serve both your needs and the company's goals. Rest assured, we stand ready to provide whatever support you require to thrive in your role. Your success is our success, and we're dedicated to empowering you with the flexibility and resources necessary to achieve it. > [!TIP] GLOBAL INTERNET WITH A NO GLOBAL LEGAL FRAMEWORK > While the internet enables global hiring, legal constraints may limit our ability to employ people from certain countries. We strive to overcome these challenges, but can't guarantee employment if we lack legal representation in your location. We'll always be transparent about such limitations during the hiring process. ## Communication In this setup, it's important to over-communicate, doing so clearly and concisely, and to include context and expectations to minimize back-and-forth. Even though we use [Slack](https://slack.com) as a communication tool, don't expect it to be used synchronously. Avoid pings and don't expect people to respond immediately. It's also important to feel comfortable having multiple tasks in progress, so that you can make progress on something else while waiting for feedback or a response. If a non-important conversation is turning into a long thread, move it out of Slack into [GitHub](https://github.com/tuist). **GitHub is the source of truth where important conversations and decisions should be captured** for future reference. We expect you to nudge people to move the conversation to GitHub if it's relevant. ## Agency We believe in giving you the agency to make decisions and take ownership of your work. **We trust you to make the right decisions and to ask for help** when you need it. We don't micromanage, but we do expect you to communicate your progress and blockers clearly and proactively. If you are unable to make decisions because you don't have enough context or because you're blocked, don't hesitate to ask for help. We're here to support you and help you grow. Look at these moments as opportunities to improve our processes, handbook, and tools to assist future team members in similar situations. You'll be informed of the priorities, and you'll be expected to make decisions based on them. If you're unsure about the priority of a task, ask for clarification. ## Innovate Many organizations cargo-cult existing processes and tools without questioning their effectiveness. For example, [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) providers have cargo-culted proprietary YAMLs as an interface layer between them and repositories, despite the ongoing pain and frustration this causes developers. *What if we could do better?* We need you to think different, to challenge the status quo, and to propose improvements to our processes and tools. Don't be afraid to do so. Share you ideas and let them be challenged by the team. We invested in creating an environment where innovation is possible, and we want you to take advantage of it. --- URL: "/people/values" LLMS_URL: "/people/values.md" title: "Values" titleTemplate: ":title | People | Tuist Handbook" description: "Learn about the values that we look for in our contributors and employees." --- # Values At Tuist, we embrace the spirit of open source by inviting diverse ideas and contributions from people around the world. From the outset, we've dedicated resources to ensure Tuist is a welcoming project for everyone, guiding them from their initial idea to a meaningful contribution. This commitment has made Tuist a uniquely humane project. Whether you are joining Tuist as a contributor or an employee, here are the values we cherish: - **Be Nice:** Kindness and respect are the foundations of a healthy community. We are all humans and should treat each other accordingly. - **Be Thankful:** Every contribution is valuable, whether it's a small typo fix or a major feature. Always express gratitude for the efforts of others. - **Be Empathetic:** We come from diverse backgrounds and experiences. Practice empathy and understanding, and never assume bad intentions. - **Be Supportive:** Help each other. Offer assistance when you see someone struggling and acknowledge great work with a shoutout. - **Be Calm:** The best ideas come from a calm mind. If you feel overwhelmed or stressed, take a break. Communicate any issues that are causing stress. - **Be Honest:** Honesty builds trust, which in turn drives motivation. Always be truthful and transparent. At Tuist, we don't subscribe to the ["move fast and break things"](https://en.wikipedia.org/wiki/Move_fast_and_break_things) philosophy. Instead, we believe in moving thoughtfully to create long-lasting, joyful projects. We provide a safe space for our users and contributors, inspiring and motivating them to build great things. This is the essence of being a calm company. ## Productivity, creativity, and vision Great ideas need time and space to develop; there are no shortcuts. When we rush, like a horse with blinders, we lose sight of the bigger picture. At Tuist, we don't focus on a finish line because we believe in the endless journey of creating a top-notch productivity platform for app developers. Fostering a culture of calmness is essential to crafting the best version of Tuist. It allows us to identify needs, cross-pollinate ideas from various ecosystems, tinker, have fun, and share insights with others. This intentional pace ensures we nurture creativity and vision, leading to innovative and thoughtful solutions. So yes, we intentionally move slow. --- URL: "/product/needs-pool" LLMS_URL: "/product/needs-pool.md" title: "Needs pool" titleTemplate: ":title | Product | Tuist Handbook" description: "This document captures the needs of people using Tuist to get ideas on how to improve the product." --- # Needs pool Tuist must solve real needs that people have. Sometimes, those ideas come from us [eating our own food](https://en.wikipedia.org/wiki/Eating_your_own_dog_food). Other times, they come from conversations with developers and organizations. When we've identified that a need is real and that it's worth solving because it aligns with our vision and is very common among teams, we should capture it here. The following sections capture the needs that we've identified so far organized by product area and priority. > [!TIP] FOCUS ON THE PROBLEM, NOT THE SOLUTION > Ensure you put the focus on the need detailing it as much as possible and including the impact it has on the person or organization. You are free to include potential solutions for anyone to consider, but the focus should be on the problem. > [!NOTE] GITHUB ISSUES > Issues are reserved for bugs and small features that are ready to be implemented. For broader and more strategic ideas, we use this document. ## Projects ### High priority
#### Teams can't express a group of targets through the CLI interface Commands like `tuist generate` require passing a list of arguments representing targets the command targets. This is cumbersome, and leads to teams building their own scripts on top of Tuist. We should extend the targets API to pass unstructured metadata that they can use from commands, for example `tuist generate domain:foo`. In the future, we can introduce some structure for example team IDs, which an be used server-side to correlate projects data with teams. The same grouping mechanism can be used in commands like `tuist graph` to filter the output. ### Medium priority
##### Teams can't codify dependency rules to be enforced It's common that teams have a set of rules around what dependencies are allowed in their projects. For example, a feature module can't depend on another feature module implementation. Teams had to build their own tools that parse the output of `tuist graph` and run validations on top of it. It'd be great if Tuist could provide a way to codify those rules and enforce them, for example through a `tuist lint links` command. ## Unlockers Unlockers is foundational investment that will enable solving other needs in the future. ### Medium priority
#### Swift-based automation DSL People are eager to have a Swift-based Fastlane. However, none of the attempts reached a level of adoption that would make them a standard. We believe it's because many of those attempts have disregarded the importance of extensibility in enabling a community of plugin developers. We should invest in a Swift-based automation DSL that is extensible and allows developers to build plugins that can be shared with the community. --- URL: "/security/access-and-risk-management/access-control-policy" LLMS_URL: "/security/access-and-risk-management/access-control-policy.md" title: "Access control policy" titleTemplate: ":title | Access and risk management | Security | Tuist Handbook" description: "To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives." --- # Access control policy - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** Oct 16, 2024 ## Purpose To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives. ## Scope All Tuist GmbH information systems that process, store, or transmit confidential data as defined in the Tuist GmbH Data Management Policy. This policy applies to all employees of Tuist GmbH and to all external parties with access to Tuist GmbH networks and system resources. ## General requirements Access to information computing resources is limited to personnel with a business requirement for such access. Access rights shall be granted or revoked in accordance with this Access Control Policy. ## Business requirements of Access Control Policy Tuist GmbH shall determine the type and level of access granted to individual users based on the "principle of least privilege." This principle states that users are only granted the level of access absolutely required to perform their job functions, and is dictated by Tuist GmbH's business and security requirements. Permissions and access rights not expressly granted shall be, by default, prohibited. Tuist GmbH's primary method of assigning and maintaining consistent access controls and access rights shall be through the implementation of Role-Based Access Control (RBAC). Wherever feasible, rights and restrictions shall be allocated to groups. Individual user accounts may be granted additional permissions as needed with approval from the system owner or authorized party. All privileged access to production infrastructure shall use Multi-Factor Authentication (MFA). ## Access to networks and network services The following security standards shall govern access to Tuist GmbH networks and network services: - Technical access to Tuist GmbH networks must be formally documented including the standard role or approver, grantor, and date - Only authorized Tuist GmbH employees and third-parties working off a signed contract or statement of work, with a business need, shall be granted access to the Tuist GmbH production networks and resources - Tuist GmbH guests may be granted access to guest networks after registering with office staff without a documented request - Remote connections to production systems and networks must be encrypted ## Customer access management When configuring cross-account access using AWS IAM roles, you must use a value you generate for the external ID, instead of one provided by the customer, to ensure the integrity of the cross account role configuration. A partner-generated external ID ensures that malicious parties cannot impersonate a customer's configuration and enforces uniqueness and format consistency across all customers. The external IDs used must be unique across all customers. Re-using external IDs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN of customer B along with the external ID of customer B. Customers must not be able to set or influence external IDs. When the external ID is editable, it is possible for one customer to impersonate the configuration of another. ## User access management Tuist GmbH requires that all personnel have a unique user identifier for system access, and that user credentials and passwords are not shared between multiple personnel. Users with multiple levels of access (e.g. administrators) should be given separate accounts for normal system use and for administrative functions wherever feasible. Root, service, and administrator accounts may use a password management system to share passwords for business continuity purposes only. Administrators shall only use shared administrative accounts as needed. If a password is compromised or suspected of compromise the incident should be escalated to the information security team immediately and the password must be changed. ## User registration and deregistration Only authorized administrators shall be permitted to create new user IDs, and may only do so upon receipt of a documented request from authorized parties. User provisioning requests must include approval from data owners or Tuist GmbH management authorized to grant system access. Prior to account creation, administrators should verify that the account does not violate any Tuist GmbH security or system access control policies such as segregation of duties, fraud prevention measures, or access rights restrictions. User IDs shall be promptly disabled or removed when users leave the organization or contract work ends in accordance with SLAs. User IDs shall not be re-used. ## Inactive and dormant user IDs Independently of the termination process, user IDs shall be retired based on inactivity so that accounts that are no longer used cannot remain available as an attack surface: - **Disable or suspend at 180 days.** Any user ID that has not been used to authenticate for 180 consecutive days shall be disabled or suspended. A disabled account retains its identity and history but cannot be used to authenticate. - **Delete at 365 days.** Any user ID that has remained inactive for 365 consecutive days shall be deleted. Deletion removes the account and its credentials; records required for audit purposes are retained separately in accordance with the Data Management Policy. - **Re-enabling.** A disabled account may only be re-enabled through the standard access request process described in Appendix A, including manager approval. Re-enabling is not a helpdesk action. - **Service and system accounts.** Non-human accounts are exempt from the inactivity thresholds above, because a low authentication rate is expected behaviour for many of them. Instead, every service account shall be reviewed during the access review cycle and shall be disabled and then removed when its owning system or integration is decommissioned. Service accounts without an identified owner shall be disabled immediately. - **Break-glass accounts.** Emergency access accounts are exempt from the inactivity thresholds, are reviewed at each access review, and their use is logged and alerted on in accordance with the [Logging and monitoring policy](/security/secure-development-and-operations/logging-and-monitoring-policy). ### Monitoring inactivity - Where a system supports automatic expiry of inactive accounts, that setting shall be enabled and configured to the thresholds above. - Where a system does not support automatic expiry, last-login data shall be collected during the quarterly inactivity check and accounts crossing a threshold shall be actioned manually. - The inactivity check shall be run at least quarterly across all systems in the Access Matrix (Appendix B) and its results documented. Quarterly checks are sufficient to enforce a 180-day threshold while keeping the process proportionate to the size of the team. - Each inactivity check shall record the systems examined, the accounts disabled, the accounts deleted, and any documented exceptions. ## User access provisioning - New employees and/or contractors are not to be granted access to any Tuist GmbH production systems until after they have completed all HR on-boarding tasks, which may include but is not limited to signed employment agreement, intellectual property agreement, and acknowledgement of Tuist GmbH's information security policy - Access should be restricted to only what is necessary to perform job duties - No access may be granted earlier than official employee start date - Access requests and rights modifications shall be documented in an access request ticket or email. No permissions shall be granted without approval from the system or data owner or management - Records of all permission and privilege changes shall be maintained for no less than one year ## Management of privileged access Tuist GmbH shall ensure that the allocation and use of privileged access rights are restricted and managed judiciously. The objective is to ensure that only authorized users, software components, and services are granted privileged access rights. Tuist GmbH will ensure that access and privileges conform to the following standard: - Identify and Validate Users: Identify users who require privileged access for each system and process. - Allocate Privileged Rights: Provision access rights basing allocations on specific needs and competencies, and adhering strictly to the access control policy. - Maintain Authorization Protocols: maintain records of all privileged access allocations. - Enforce Strong Authentication: Require MFA for all privileged access. - Prevent Generic Admin ID Usage: prevent the usage of generic administrative user IDs - Ensure Logging and Auditing: Log all privileged logins and activity ## User access reviews Administrators shall perform access rights reviews of user, administrator, and service accounts on an annually basis to verify that user access is limited to systems that are required for their job function. Access reviews shall be documented. Access reviews may include group membership as well as evaluations of any specific or exception-based permission. Access rights shall also be reviewed as part of any job role change, including promotion, demotion, or transfer within the company. ## Removal & adjustment of access rights The access rights of all users shall be promptly removed upon termination of their employment or contract, or when rights are no longer needed due to a change in job function or role. The maximum allowable time period for access termination is 24 business hours. ## Access provisioning, deprovisioning, and change procedure The Access Management Procedure for Tuist GmbH systems can be found in Appendix A to this policy. ## Segregation of duties Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of Tuist GmbH assets. When provisioning access, care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered when determining access levels for individuals and groups. ## User responsibility for the management of secret authentication information Control and management of individual user passwords is the responsibility of all Tuist GmbH personnel and third-party users. Users shall protect secret authentication information in accordance with the Information Security Policy. ## Password policy - Where feasible, passwords for confidential systems shall be configured to have at least eight (8) or more characters, one upper case, one lower case, one special character, one number - Systems shall be configured to remember and prohibit reuse of passwords for last 16 passwords used - Passwords shall be set to lock out after 6 failed attempts - For manual password resets, a user's identity must be verified prior to changing passwords - Do not use secret questions (place of birth, etc.) as a sole password reset requirement ## Information access restriction Applications must restrict access to program functions and information to authorized users and support personnel in accordance with the defined access control policy. The level and type of restrictions applied by each application should be based on the individual application requirements, as identified by the data owner. The application-specific access control policy must also conform to Tuist GmbH policies regarding access controls and data management. Prior to implementation, evaluation criteria are to be applied to application software to determine the necessary access controls and data policies. Assessment criteria include, but are not limited to: - Sensitivity and classification of data. - Risk to the organization of unauthorized access or disclosure of data - The ability to, and granularity of, control(s) on user access rights to the application and data stored within the application - Restrictions on data outputs, including filtering sensitive information, controlling output, and restricting information access to authorized personnel - Controls over access rights between the evaluated application and other applications and systems - Programmatic restrictions on user access to application functions and privileged instructions - Logging and auditing functionality for system functions and information access - Data retention and aging features All unnecessary default accounts must be removed or disabled before making a system available on the network. Specifically, vendor default passwords and credentials must be changed on all Tuist GmbH systems, devices, and infrastructure prior to deployment. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, and Simple Network Management Protocol (SNMP) community strings where feasible. ## Secure log-on procedures Secure log-on controls shall be designed and selected in accordance with the sensitivity of data and the risk of unauthorized access based on the totality of the security and access control architecture. ## Password management system Systems for managing passwords should be interactive and assist Tuist GmbH personnel in maintaining password standards by enforcing password strength criteria including minimum length, and password complexity where feasible. All storage and transmission of passwords is to be protected using appropriate cryptographic protections, either through hashing or encryption. ## Use of privileged utility programs Use of utility programs, system files, or other software that might be capable of overriding system and application controls or altering system configurations must be restricted to the minimum personnel required. Systems are to maintain logs of all use of system utilities or alteration of system configurations. Extraneous system utilities or other privileged programs are to be removed or disabled as part of the system build and configuration process. Management approval is required prior to the installation or use of any ad hoc or third-party system utilities. ## Access to program source code Access to program source code and associated items, including designs, specifications, verification plans, and validation plans shall be strictly controlled in order to prevent the introduction of unauthorized functionality into software, avoid unintentional changes, and protect Tuist GmbH intellectual property. All access to source code shall be based on business need and must be logged for review and audit. ## Exceptions Requests for an exception to this Policy must be submitted to the IT Manager for approval. ## Violations & enforcement Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. ## APPENDIX A — Access management procedure ### 1. Access Request Process #### 1.1 Standard Access Provisioning - **Onboarding Completion:** HR sends an email to the IT Service Desk upon completion of the employee onboarding process, generating service tickets for access. - **Standard Provisioning:** IT provisions access to company-wide systems based on the employee's role according to the Access Matrix (Appendix B). #### 1.2 GitHub-Based Access Request Process - **Request Creation:** For additional access beyond standard role-based access, employees must create an issue in the [access](https://github.com/tuist/access) repository using the provided template. - **Required Information:** The request must include: - Requestor information (name, role, department, manager) - Specific systems or resources requested - Type of access needed (read, write, admin, etc.) - Business justification - Duration of access (permanent or temporary with end date) - Additional justification for privileged access, if applicable #### 1.3 Review and Approval - **Manager Approval:** The requestor's manager must review and approve the request by commenting on the GitHub issue. - **System Owner Approval:** For sensitive systems, the system owner must also approve the request. - **Documentation:** All approvals must be documented directly in the GitHub issue. #### 1.4 Implementation - **Provisioning:** Upon approval, IT will provision the requested access and document the implementation details in the GitHub issue. - **Notification:** The requestor will be notified via a comment in the GitHub issue when access has been granted. - **Issue Closure:** The GitHub issue will be closed only after access has been successfully granted and verified. ### 2. Access Review and Revocation #### 2.1 Periodic Reviews - **Regular Audits:** IT will conduct periodic reviews of access rights by auditing the GitHub issues repository. - **Inactivity Check:** IT will run a quarterly inactivity check across all systems in the Access Matrix, disabling user IDs inactive for 180 days and deleting user IDs inactive for 365 days as required by the Inactive and dormant user IDs section of this policy. - **Documentation:** Results of access reviews and inactivity checks will be documented in separate GitHub issues tagged with "access-review". #### 2.2 Role Changes and Departures - **Role Change Process:** When an employee changes roles, a new GitHub issue must be created to document required access changes. - **Departure Process:** When an employee leaves, HR will create a GitHub issue to initiate the access revocation process. - **Timeframe:** All access revocation must be completed within 24 business hours of an employee's departure. ### 3. Audit Trail - **Issue History:** All GitHub issues related to access requests will be maintained as a permanent record. - **Retention:** Access request records will be retained for a minimum of one year. - **Compliance Reporting:** The GitHub repository will serve as the primary source for access management during compliance audits. ## APPENDIX B — Access matrix | Role | Email | Google Workspace | Slack | GitHub | CRM | Infrastructure | Databases | Cloudflare | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Founder | x | x | x | x | x |x | x | x | | Engineer | x | x | x | x | | x | | | | Product designer | x | x | x | x | | | | | --- URL: "/security/access-and-risk-management/risk-management-policy" LLMS_URL: "/security/access-and-risk-management/risk-management-policy.md" title: "Risk management policy" titleTemplate: ":title | Access and risk management | Security | Tuist Handbook" description: "To define actions to address Tuist GmbH information security risks and opportunities. To define a plan for the achievement of information security and privacy objectives." --- # Risk management policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To define actions to address Tuist GmbH information security risks and opportunities. To define a plan for the achievement of information security and privacy objectives. ## Scope - All Tuist GmbH IT systems that process, store or transmit confidential, private, or business-critical data. - Risks that could affect the medium to long-term goals of Tuist GmbH should be considered as well as risks that will be encountered in the day-to-day delivery of services. - Tuist GmbH risk management systems and processes will be targeted to achieve maximum benefit without increasing the bureaucratic burden and ultimately affecting core service delivery to the organization. - Tuist GmbH will therefore consider the materiality of risk in developing systems and processes to manage risk. - This Policy applies to all employees of Tuist GmbH and to all external parties, including but not limited to Tuist GmbH consultants and contractors, business partners, vendors, suppliers, outsource service providers, and other third party entities with access to Tuist GmbH networks and system resources. ## Risk management statement Inadequate IT risk management exposes Tuist GmbH to risks including compromise of Tuist GmbH or customer network systems, services and information, cyber-attacks, contractual, or legal issues. Tuist GmbH will ensure that risk management plays an integral part in the governance and management of the organization at a strategic and operational level. The purpose of a risk management policy is designed to ensure that it achieves its stated business plan aims and objectives. ## Risk management strategy Tuist GmbH has developed processes to identify those risks that will hinder the achievement of its strategic and operational objectives. Tuist GmbH will therefore ensure that it has in place the means to identify, analyze, control and monitor the strategic and operational risks it faces using this risk management policy based on best practices. Tuist GmbH will ensure the risk management strategy and policy are reviewed regularly and that internal audit functions are responsible for ensuring: - The risk management policy is applied to all applicable areas of Tuist GmbH - The risk management policy and its operational application are regularly reviewed - Non-compliance is reported to appropriate company officers and authorities ## Practical application of risk management Tuist GmbH has adopted a standard format for use in the identification of risks, their classification, and evaluation. The format is based on the following NIST and ISO standards and frameworks: - ISO 27005 - NIST 800-30 - NIST 800-37 Risks are assessed and ranked according to their impact and their likelihood of occurrence. A formal Risk Assessment, and network penetration tests, will be performed at least annually and shall take into consideration the results of any technical vulnerability management activities performed in accordance with the *Operations Security Policy* and the *Penetration Testing Policy*. ## Risk categories Tuist GmbH will consider and assess risks across the organization. Risk categories that are considered for evaluation include: - Access control - Artificial intelligence - Asset management - Business continuity and disaster recovery - Communications security - Compliance - Cryptography - Environmental, social, and governance - Fraud - Incident response management - Information security operations - Information security policies - Operations security - People operations - Physical and environmental security - Privacy - Software development and acquisition - Trustworthiness - Vendor relationships Each risk will be assessed as to its Likelihood and Impact. Likelihood can range from 1 ("Very unlikely") to 5 ("Very likely"). Impact can range from 1 ("Very low impact") to 5 ("Very high impact"). ## Risk criteria The criteria for determining risk is the combined likelihood and impact of an event adversely affecting the confidentiality, availability, integrity, or privacy of organizational and customer information, personally identifiable information (PII), or business information systems. For all risk inputs such as risk assessments, vulnerability scans, penetration tests, bug bounty programs, etc., Tuist GmbH management shall reserve the right to modify risk rankings based on its assessment of the nature and criticality of the system processing, as well as the nature, criticality and exploitability (or other relevant factors and considerations) of the identified vulnerability. All penetration testing activities shall follow the requirements outlined in the Penetration Testing Policy. ## Risk response, treatment, and tracking Risk will be prioritized and maintained in a risk register where they will be prioritized and mapped using the approach contained in this policy. The following responses to risk should be employed: - **Mitigate:** Tuist GmbH may take actions or employ strategies to reduce the risk. - **Accept:** Tuist GmbH may decide to accept and monitor the risk at the present time. This may be necessary for some risks that arise from external events. - **Transfer:** Tuist GmbH may decide to pass the risk on to another party. For example contractual terms may be agreed to ensure that the risk is not borne by Tuist GmbH or insurance may be appropriate for protection against financial loss. - **Avoid:** the risk may be such that Tuist GmbH could decide to cease the activity or to change it in such a way as to end the risk. Where Tuist GmbH chooses a risk response other than "Accept" or "Avoid" it shall develop a Risk Treatment Plan. ## Risk management procedures The procedure for managing risk will meet the following criteria 1. Tuist GmbH will maintain a Risk Register and Treatment Plan. 2. Risks are ranked by ‘likelihood' and ‘severity/impact' as critical, high, medium, low, and negligible. 3. Overall risk shall be determined through a combination of likelihood and impact. 4. Risks may be evaluated to estimate potential monetary loss where possible. 5. Tuist GmbH will respond to risks in a prioritized fashion. Remediation priority will consider the risk likelihood and impact, cost, work effort, and availability of resources. Multiple remediations may be undertaken simultaneously 6. Regular reports will be made to the senior leadership of Tuist GmbH to ensure risks are being mitigated appropriately, and in accordance with business priorities and objectives. ## Information security in project management Tuist GmbH shall consider information security risk as a part of all projects that are technical in nature or which can pose a risk to the company, regardless of size, duration, or domain. From the initial planning, through completion of a project, appropriate assessment and mitigation of information security risks is essential, involving: - initial information security risk assessments, - early identification and addressing of information security requirements, and - ongoing assessment and management of risks, especially concerning internal and external project communications. ## Roles and responsibilities The following table outlines the specific risk management activities and responsibilities associated with each role. | Role | Responsibility | | --- | --- | | President/CEO | Ultimately responsible for the acceptance and/or treatment of any risks to the organization. | | Chief Information Officer | Can approve the avoidance, remediation, transference, or acceptance of any risk cited in the Risk Register. | | IT Manager / Systems Engineer | Shall be responsible for the identification and treatment plan development of all Information Security related risks. This person shall be responsible for communicating risks to top management and adopting risk treatments in accordance with executive direction. | ## APPENDIX A - Risk assessment process The following is a high-level overview of the process used by Tuist GmbH to assess and manage information security related risks. The process discussed below is based on NIST 800-30 and provides guidance to Tuist GmbH on how to: - Prepare and conduct an effective risk assessment. - Communicate and share the assessment results and risk-related information. - Manage and maintain risks on an ongoing basis. The risk assessment process is comprised of the following steps: 1. Prepare for the assessment 2. Conduct the assessment 3. Communicate the assessment 4. Maintain the assessment ### Step 1: Prepare for the Assessment In this step, the objective is to establish context for the risk assessment. This can be accomplished by performing the following: - Identify the purpose of the assessment - Determine the information that the assessment is intended to produce and the decisions the assessment is intended to support. - Identify the scope of the assessment - Determine the organizational function or process that is applicable, the associated time frame and any applicable architectural or technological considerations. - Identify any assumptions or constraints associated with the assessment - Determine assumptions in key areas relevant to the risk assessment including: - Organizational priorities - Business objectives - Resource availability - Skills and expertise of risk assessment team - Identify sources of information - Architectural / technological diagrams and system configurations - Legal and regulatory requirements - Threat Sources - Threat Events - Vulnerabilities and influencing conditions - Potential Impacts - Existing Controls ### Step 2: Conduct the Assessment In this step, the objective is to produce a list of information security related risks that can be prioritized by risk level and used to inform risk response decisions. This can be accomplished by performing the following: - Identify Threat Sources - Determine and characterize threat sources relevant to and of concern to Tuist GmbH, including but not limited - Human (Intentional or Unintentional / Internal or External) - Environmental - Natural - System or Equipment - Consider the following when identifying threat sources: - Capability - Motive / Intent - Intentionally targeted people, processes, and/or technologies - Unintentionally targeted people, processes, and/or technologies - Identify Threat Events - Determine what threat events could be produced by the identified threat sources that have potential to impact Tuist GmbH. - Consider the relevance of the events and the sources that could initiate the events. - Identify Vulnerabilities - Determine the vulnerabilities associated to people, process and/or technologies that could be exploited by the identified threat sources and threat events. - Consider any influencing conditions that could affect and aid in successful exploitation. - Determine Likelihood - Determine the likelihood that the identified threat sources would initiate the identified threat events and could successfully exploit any identified vulnerabilities. - Consider the following when determining the likelihood: - Characteristics of the threat sources that could initiate the events - Capability - Motive/Intent - Opportunity - The vulnerabilities and/or influencing conditions identified - Tuist GmbH's exposure based on any safeguards/countermeasures planned or implemented to prevent or mitigate such events. - Determine Impact - Determine the impact to Tuist GmbH's business objectives, operations, assets, individuals, customers, and/or other organizations by considering the following: - Business / Operational Impacts - Financial Damage - Reputation Damage - Legal or Regulatory Issues - When determining impact, also take into consideration any safeguards/countermeasures planned or implemented by Tuist GmbH that would mitigate or lessen the impact. - Determine Risk - Determine the overall information security related risks to Tuist GmbH by combining the following: - The likelihood of the event occurring. - The impact that would result from the event. - The risk to Tuist GmbH is proportional to the likelihood and impact of an event - Higher Risk Event: Is more likely to occur and the resulting impact will be greater. - Lower Risk Event: Is less likely to occur and the resulting impact will be minimal if any. ### Step 3: Communicate and Share the Risk Assessment Results In this step, the objective is to ensure that decision makers across the Tuist GmbH and executive leadership have the appropriate risk-related information needed to inform and guide risk decisions. - Communicate the Results - Communicate the risk assessment results to Tuist GmbH decision maker and executive leadership to help drive risk based decisions and obtain the necessary support for the risk response. - Share the risk assessment and risk-related information with the appropriate personnel at Tuist GmbH to help support the risk response efforts. ### Step 4: Maintain the Assessment In this step, the objective is to keep current, the specific knowledge related to the risks that Tuist GmbH incurs. The results of the assessments inform, and drive risk based decisions and guide ongoing risk responses efforts. - Monitor Risk Factors - Conduct ongoing monitoring of the risk factors that contribute to changes in risk to Tuist GmbH's business objectives, operations, assets, individuals, customers, and/or other organizations. - Maintain and Update the Assessment - Update existing risk assessments using the results from ongoing monitoring of risk factors and by conducting additional assessments, at minimum annually. ## APPENDIX B - Risk assessment matrix and description key Each risk will be assessed as to its Likelihood and Impact. Likelihood can range from 1 ("Very unlikely") to 5 ("Very likely"). Impact can range from 1 ("Very low impact") to 5 ("Very high impact").
Likelihood
Very unlikely: 1 Unlikely: 2 Somewhat likely: 3 Likely: 4 Very likely: 5
Very high impact: 5 5 10 15 20 25
High impact: 4 4 8 12 16 20
Medium impact: 3 3 6 9 12 15
Low impact: 2 2 4 6 8 10
Very low impact: 1 1 2 3 4 5
Risk level Description
Low (1 - 4) A threat event could be expected to have a limited adverse effect on organizational operations, mission capabilities, assets, individuals, customers, or other organizations.
Med (5 - 14) A threat event could be expected to have a serious adverse effect on organizational operations, mission capabilities, assets, individuals, customers, or other organizations.
High (15 - 25) A threat event could be expected to have a severe adverse effect on organizational operations, mission capabilities, assets, individuals, customers, or other organizations.
| Impact | Description | Score | | --- | --- | --- | | Very low impact (1) | A threat event could be expected to have almost no adverse effect on organizational operations, mission capabilities, assets, individuals, customers, or other organizations. | 1 | | Low impact (2) | A threat event could be expected to have a limited adverse effect, meaning: degradation of mission capability yet primary functions can still be performed; minor damage; minor financial loss; or range of effects is limited to some cyber resources but no critical resources. | 2 | | Medium impact (3) | A threat event could be expected to have a serious adverse effect, meaning: significant degradation of mission capability yet primary functions can still be performed at a reduced capacity; minor damage; minor financial loss; or range of effects is significant to some cyber resources and some critical resources. | 3 | | High impact (4) | A threat event could be expected to have a severe or catastrophic adverse effect, meaning: severe degradation or loss of mission capability and one or more primary functions cannot be performed; major damage; major financial loss; or range of effects is extensive to most cyber resources and most critical resources. | 4 | | Very high impact (5) | A threat event could be expected to have multiple severe or catastrophic adverse effects on organizational operations, assets, individuals, or other organizations. Range of effects is sweeping, involving almost all cyber resources. | 5 | | Likelihood | Description | Score | | --- | --- | --- | | Very unlikely (1) | A threat event is so unlikely that it can be assumed that its occurrence may not be experienced. A threat source is not motivated or has no capability, or controls are in place to prevent or significantly impede the vulnerability from being exploited. | 1 | | Unlikely (2) | A threat event is unlikely, but there is a slight possibility that its occurrence may be experienced. A threat source lacks sufficient motivation or capability, or controls are in place to prevent or impede the vulnerability from being exploited. | 2 | | Somewhat unlikely (3) | A threat event is likely, and it can be assumed that its occurrence may be experienced. A threat source is motivated or poses the capability, but controls are in place that may significantly reduce or impede the successful exploitation of the vulnerability. | 3 | | Likely (4) | A threat event is likely, and it can be assumed that its occurrence will be experienced. A threat source is highly motivated or poses sufficient capability and resources, but some controls are in place that may reduce or impede the successful exploitation of the vulnerability. | 4 | | Very likely (5) | A threat event is highly likely, and it can be assumed that its occurrence will be experienced. A threat source is highly motivated or poses sufficient capability or resources, but no controls are in place or controls that are in place are ineffective and do not prevent or impede the successful exploitation of the vulnerability. | 5 | ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/access-and-risk-management/third-party-risk-management-policy" LLMS_URL: "/security/access-and-risk-management/third-party-risk-management-policy.md" title: "Third-party risk management policy" titleTemplate: ":title | Access and risk management | Security | Tuist Handbook" description: "To ensure protection of the organization's data and assets that are shared with, accessible to, or managed by suppliers, including external parties or third-party organizations such as service providers, vendors, and customers, and to maintain an agreed level of information security and service delivery in line with supplier agreements." --- # Third-party risk management policy - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** January 7th, 2025 ## Purpose To ensure protection of the organization's data and assets that are shared with, accessible to, or managed by suppliers, including external parties or third-party organizations such as service providers, vendors, and customers. This document outlines the baseline security controls that Tuist GmbH expects partners and other third-party companies to meet when interacting with Tuist GmbH Confidential data. ## Scope This policy applies to all employees of Tuist GmbH and to all external parties, including consultants, contractors, business partners, vendors, suppliers, outsourced service providers, and other third-party entities with access to Tuist GmbH data, systems, networks, or system resources. ## General requirements 1. Information security requirements for mitigating risks associated with supplier access to the organization's assets shall be agreed upon with the supplier and documented. 2. **Pre-contract due diligence** must include: - **Financial health assessment** to ensure the supplier’s stability and reliability. - **Risk assessment** to identify potential vulnerabilities and threats. - **Information security evaluation** to verify compliance with security standards. - **Compliance checks** to ensure adherence to applicable legal, regulatory, and certification frameworks. 3. Proper due diligence shall be performed prior to granting access to Tuist GmbH Confidential data, systems, or networks. Regulatory or certification requirements to be considered may include ISO 27001, SOC 2, PCI DSS, CCPA, GDPR, or other frameworks. ## Addressing security in agreements Written agreements with suppliers that access, process, store, or transmit Confidential data must include: - Acknowledgment of responsibilities for confidentiality and security. - Commitments regarding the integrity, availability, and/or privacy controls required by Tuist GmbH’s information security program. ## Technology supply chain Tuist GmbH will assess risks associated with suppliers and the technology supply chain. Agreements must address relevant risks related to information and communications technology services and products. ## Monitoring & review of third-party services 1. Tuist GmbH shall monitor and audit supplier service delivery regularly. Reviews of supplier security and performance must occur at least annually. 2. Any material changes by suppliers will be risk-assessed and agreements updated as necessary. ## Third-party risk management Tuist GmbH shall identify, document, and mitigate risks posed by third-party access to Confidential data or systems. No data shall be shared with third parties without a risk assessment and a fully executed contract outlining service levels and information security requirements. ## Information security for use of cloud services Cloud service usage shall comply with the following: - **Risk management**: All risks related to cloud services must align with this policy. - **Service agreements**: Protections for Tuist GmbH’s data must be clearly outlined. - **Incident management**: Cloud-related incidents will follow the Incident Response Plan. - **Exit strategy**: Vendor lock-in risks must be evaluated prior to acquisition. ## Third-party security standards All third parties must maintain reasonable organizational and technical controls. Evaluations will include: - **Information security policy**: Policies must be supported by executive management and regularly reviewed. - **Risk assessment & treatment**: Programs must assess, evaluate, and manage information and technology risks. - **Access control**: Programs must prevent unauthorized access to Tuist GmbH resources. - **Human resources**: Policies must include background checks for employees accessing Confidential data. - **Compliance**: All relevant regulations must be considered. ## Exceptions Requests for exceptions must be submitted to the IT Manager for approval. ## Violations & enforcement Violations of this policy must be reported to the IT Manager. Non-compliance may result in disciplinary actions, up to termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/business-continuity-and-data-protection/business-continuity-and-disaster-recovery-plan" LLMS_URL: "/security/business-continuity-and-data-protection/business-continuity-and-disaster-recovery-plan.md" title: "Business continuity and disaster recovery plan" titleTemplate: ":title | Business continuity and data protection | Security | Tuist Handbook" description: "The purpose of this business continuity plan is to prepare Tuist GmbH in the event of service outages caused by factors beyond our control (e.g., natural disasters, man-made events), and to restore services to the widest extent possible in a minimum time frame." --- # Business continuity and disaster recovery plan - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose The purpose of this business continuity plan is to prepare Tuist GmbH in the event of service outages caused by factors beyond our control (e.g., natural disasters, man-made events), and to restore services to the widest extent possible in a minimum time frame. ## Scope All Tuist GmbH IT systems that are business critical. This policy applies to all employees of Tuist GmbH and to all relevant external parties, including but not limited to Tuist GmbH consultants and contractors. In the event of a loss of availability of a hosting service provider, the CTO will confer with the CTO to determine an appropriate response strategy. ## General requirements In the event of a major disruption to production services and a disaster affecting the availability and/or security of the Tuist GmbH office, senior managers and executive staff shall determine mitigation actions. A disaster recovery test, including a test of backup restoration processes, shall be performed on an annual basis. ## Alternate work facilities If the Tuist GmbH office becomes unavailable due to a disaster, all staff shall work remotely from their homes or any safe location. ## Communications and escalation Executive staff and senior managers should be notified of any disaster affecting Tuist GmbH facilities or operations. Communications shall take place over approved channels such as email and [the status page](https://status.tuist.io). Key communication contacts are maintained in [this list](/security/human-and-incident-management/incident-response-management). ## Roles and responsibilities | Role | Responsibility | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | IT Manager | The IT Manager shall lead BC/DR efforts to mitigate losses and recover the corporate network and information systems. | | Departmental Heads | Each department head shall be responsible for communications with their departmental staff and any actions needed to maintain continuity of their business functions. Departmental heads shall communicate regularly with executive staff and the IT Manager. | | Managers | Managers shall be responsible for communicating with their direct reports and providing any needed assistance for staff to continue working from alternative locations. | | VP of Global Support | The VP of Global Support, in conjunction with the CEO and CFO shall be responsible for any external and client communications regarding any disaster or business continuity actions that are relevant to customers and third parties. | | VP of Engineering | The VP of Engineering, in conjunction with the VP of Global Support, shall be responsible for leading efforts to maintain continuity of Tuist GmbH services to customers during a disaster. | | Chief HR Officer | The CHRO shall be responsible for internal communications to employees as well as any action needed to maintain physical health and safety of the workforce. The CHRO shall work with the IT Manager to ensure continuity of physical security at the Tuist GmbH office. | ## Continuity of critical services Procedures for maintaining continuity of critical services in a disaster can be found in Appendix A. Recovery Time Objectives (RTO) and Recovery Point Objects (RPO) can be found in Appendix B. Strategy for maintaining continuity of services can be seen in the following table: ## Plan activation This BC/DR shall be automatically activated in the event of the loss or unavailability of the Tuist GmbH office, or a natural disaster (i.e., severe weather, regional power outage, earthquake) affecting the larger Berlin, Germany region. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. ## Appendix A - Business continuity procedures by scenario **Business Continuity Scenarios** ### HQ Offline (power and/or network) - CRM, Telephony, Video Conferencing/Screen Share & Corp Email unaffected - SUPPORT unaffected - HQ Staff offline (30-60 minutes) - Remote Staff unaffected (EU) #### Procedure: 1. HQ Staff relocate to home offices (30-60 minutes) 2. Verify Telephony, CRM, & Email Connectivity at home offices (10 minutes) 3. Remotely resume normal operations ### Colo Offline (power and/or network) - CRM, Telephony, Video Conferencing/Screen Share & Corp Email unaffected - SUPPORT Offline - Production Database offline (redundant) - HQ Staff unaffected - Remote Staff unaffected (EU) #### Procedure: 1. Notify Customer Base that proactive monitoring is offline 2. Normal operations continue ### Disaster Event at HQ - CRM, Telephony, Video Conferencing/Screen Share & Corp Email unaffected - SUPPORT offline - HQ Staff offline (variable impact) - Remote Staff unaffected (EU) #### Procedure: 1. Activate Remote Staff (EU) 2. Notify Customer Base of impaired functions & potential delays 3. Commandeer Field Resources for Critical Response (SE Teams) ### SaaS Tools Down - CRM, Telephony, Video Conferencing/Screen Share, or Corp Email Affected - SUPPORT partially affected (no new cases, manual triage required) - HQ Staff unaffected - Remote Staff unaffected (EU) #### Procedure: ##### Telephony Down 1. Notify Customer Base to use Support Portal or Email 2. Support Staff use Mobile Phones and/or Land Lines as needed ##### Email Down (Gmail/Corp Email) 1. Support Staff manually manage 'case' related communications 2. Support Staff use alternate email accounts as needed (Hotmail) ##### CRM Down 1. Notify Customer Base that CRM is down 2. Activate 'Spreadsheet' Case Tracking (Google Sheets) 3. Leverage 'Production' Database for Entitlements, Case History, Configuration data. ##### Video Conferencing/ScreenShare Down (Zoom) 1. Support Staff utilize alternate service as needed ## Appendix B - RTOs/RPOs | Rank | Asset | Affected Assets | Business Impact | Users | Owners | Recovery Time Objective (RTO) | Recovery Point Objective (RPO) | Comments / Gaps | | ---- | ------------ | ----------- | ---- | ----- | ----------- | ----------------------------- | ------------------------------ | --------------- | | 1 | Kubernetes clusters | Network | Core services | All | Engineering | 1 hour | | The recovery might depend on the vendor. | | 2 | Tigris Storage | Network | Core services | All | Engineering | 1 hour | | The recovery might depend on the vendor. | | 3 | PostgreSQL database | Network | Core services | All | Engineering | 1 hour | | The recovery might depend on the vendor. | | 4 | GitHub | Network | Inability to deploy critical fixes to our production infrastructure | All | Engineering | 30 min | | The recovery might depend on the vendor. | | 5 | Slack | Network | Inability to communicate with the team | All | Engineering | 30 min | | The recovery might depend on the vendor. | | 6 | Google Workspace | Network | Inability to perform administrative tasks | All | Engineering | 30 min | | The recovery might depend on the vendor. | | 7 | Company laptops | Hardware | Inability to work | All | IT Ops | 1 hour | | The recovery might depend on the vendor. | | 8 | Corporate office | Site | Inability to work | All | IT Ops | 1 hour | | The recovery might depend on the vendor. | | 9 | Corporate network | Network | Inability to work | All | IT Ops | 1 hour | | The recovery might depend on the vendor. | --- URL: "/security/business-continuity-and-data-protection/cryptography-policy" LLMS_URL: "/security/business-continuity-and-data-protection/cryptography-policy.md" title: "Cryptography policy" titleTemplate: ":title | Business continuity and data protection | Security | Tuist Handbook" description: "To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information. This policy establishes requirements for the use and protection of cryptographic keys and cryptographic methods throughout the entire encryption lifecycle." --- # Cryptography Policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information. This policy establishes requirements for the use and protection of cryptographic keys and cryptographic methods throughout the entire encryption lifecycle. ## Scope All information systems developed and/or controlled by Tuist GmbH which store or transmit confidential data.s ## General requirements Tuist GmbH shall evaluate the risks inherent in processing and storing data, and shall implement cryptographic controls to mitigate those risks where deemed appropriate. Where encryption is in use, strong cryptography with associated key management processes and procedures shall be implemented and documented. All encryption shall be performed in accordance with industry standards, including NIST SP 800-57. Customer or confidential company data must utilize strong ciphers and configurations in accordance with vendor recommendations and industry best practices including [NIST when stored or transferred over a public network.](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines) ## Key management Access to keys and secrets shall be tightly controlled in accordance with the Access Control Policy. The following table details Tuist GmbH's approved encryption algorithms: | Domain | Key Type | Algorithm | Key Length | Max Expiration | |--------|----------|-----------|------------|----------------| | Web Certificate | RSA or ECC with SHA2+ signature | RSA or ECC with SHA2+ signature | 2048 bit or greater/RSA, 256bit or greater/ECC | Up to 1 year | | Web Cipher (TLS) | Asymmetric Encryption | Ciphers of B or greater grade on SSL Labs Rating | Varies | N/A | | Confidential Data at Rest | Symmetric Encryption | AES | 256 bit | 1 Year | | Passwords | One-way Hash | Bcrypt, PBKDF2, or scrypt, Argon2 | 256 bit+10K Stretch. Include unique cryptographic salt+pepper | N/A | | Endpoint Storage (SSD/HDD) | Symmetric Encryption | AES | 128 or 256 bit | N/A | ## Exceptions Requests for an exception to this policy must be submitted to the IT Manager for approval. A documented exception is required prior to moving, copying, or storing customer or company confidential data on any media or removable device; all portable devices and removable media containing sensitive data must be encrypted using approved standards and mechanisms. ## Violations & enforcement Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/business-continuity-and-data-protection/data-labelling-policy" LLMS_URL: "/security/business-continuity-and-data-protection/data-labelling-policy.md" title: "Data labelling policy" titleTemplate: ":title | Business continuity and data protection | Security | Tuist Handbook" description: "This policy defines how Tuist GmbH identifies sensitive information and applies the correct label to it according to the company's information classification scheme." --- # Data labelling policy - **Policy owner:** Pedro Piñera Buendía - **Effective date:** August 14, 2026 ## Purpose To ensure that sensitive information held by Tuist GmbH is identified and receives the correct label according to the company's information classification scheme, so that everyone handling that information knows which protection and handling requirements apply to it. The classification scheme itself, and the handling requirements attached to each class, are defined in the [Data Management Policy](/pdfs/security/business-continuity-and-data-protection/data-management-policy-bsi.pdf). This policy covers the process of identifying and labelling: how information gets assigned to a class, how the label is applied and made visible, and how labels are kept correct over time. ## Scope All information created, received, stored, processed, or transmitted by Tuist GmbH, in any form: documents, source code, repositories, databases, object storage, messages, tickets, dashboards, exports, and physical records. This policy applies to all employees, contractors, and third parties handling Tuist GmbH information. ## Classification scheme Tuist GmbH uses three classes. The definitions below are summarized from the Data Management Policy, which remains the authoritative source. | Class | Definition | Typical examples | | --- | --- | --- | | **Confidential** | Highly sensitive data requiring the highest level of protection. Access restricted to specific people; onward sharing requires data owner or executive approval. | Customer data, personally identifiable information, financial and banking data, payroll data, strategic plans, authentication credentials, secrets and private keys, unpublished source code, incident reports, risk assessments, vulnerability reports, litigation data | | **Restricted** | Proprietary information requiring thorough protection. Access restricted on a need-to-know basis. **This is the default for all company information unless stated otherwise.** | Internal policies, legal documents, contracts, meeting notes, internal reports, Slack messages, email | | **Public** | Information intended for public consumption that can be freely distributed. | Marketing materials, product descriptions, release notes, externally published policies | ## 1. Identifying sensitive information ### 1.1 Default classification All Tuist GmbH information is **Restricted** by default. Information is only Public once it has been deliberately reviewed and released as such. Information falls into **Confidential** whenever it meets any of the criteria below, regardless of where it is stored. ### 1.2 Identification criteria Information shall be identified as Confidential when it contains any of the following: - Data belonging to or describing a customer, including project, build, and usage data - Personal data of any identified or identifiable person, including employees, candidates, and users, whether or not it is regulated as personal data in a given jurisdiction - Authentication material: passwords, API tokens, private keys, certificates, session material, signing material - Financial data: banking details, payroll, compensation, revenue figures not yet published - Security findings: vulnerability reports, penetration test results, incident reports, risk assessments - Source code that has not been deliberately published, and infrastructure configuration. Tuist GmbH develops much of its product in the open, and publishing source is a deliberate act of publication, governed by the Publication requirement in section 3, rather than an exception to this rule. Anything not published stays Confidential. - Information subject to a confidentiality obligation under a contract, NDA, or legal hold Where a set of information mixes classes, the whole set takes the highest class present. A document containing one paragraph of customer data is Confidential in its entirety. A system takes the highest classification of any data it stores or processes. ### 1.3 Who decides The person who creates or first receives a piece of information is responsible for classifying it at that moment. The data owner for the relevant system or business area is responsible for resolving ambiguous cases and may reclassify. Where classification is genuinely unclear, the information shall be treated as Confidential until the data owner decides. Under-classification is treated as a security issue; over-classification is treated as an inconvenience. ## 2. Applying labels Labels shall be applied at the point where information is created or ingested, not retroactively at the point of sharing. ### 2.1 Documents and written content - Documents and presentations shall carry the label in the document header, footer, or title block: `Confidential`, `Restricted`, or `Public`. - Documents in shared drives shall additionally live under a folder whose access controls match the class. Folder-level classification acts as an inherited label for everything inside it. - Handbook and other externally published pages are implicitly `Public` by virtue of being published, and require no inline label. Nothing Confidential or Restricted may be published to a public surface. ### 2.2 Source code and repositories - Repository visibility is the label. Private repositories are `Confidential`. Public repositories are `Public`, having been published deliberately. - Making a repository public, or opening a previously private component, is a publication decision under section 3 and requires data owner approval. The review shall confirm that no credentials, customer data, or personal data are present anywhere in the history, not only at the current commit. - Files containing secrets shall never be committed, regardless of repository visibility. Secrets are stored in the secret manager and are `Confidential` by definition. - Configuration and infrastructure-as-code files that reference production systems shall carry a comment identifying them as `Confidential` where the repository is not itself already private. ### 2.3 Databases, object storage, and data pipelines - Database tables and columns holding Confidential data shall be identifiable from `server/data-export.md`, the register of the personal and organizational data Tuist GmbH stores, which is kept current as the schema changes. Data recorded there as belonging to a customer or to an identifiable person is Confidential under the criteria in section 1.2. - Object storage buckets and prefixes shall be classified as a whole, and the classification shall be recorded alongside the bucket's access policy. Buckets holding customer artifacts are `Confidential`. - Data exports and reports inherit the highest classification of their inputs, and the label shall be carried into the filename or the export's header. ### 2.4 Communications and tickets - Slack channels shall be classified at the channel level. Private channels default to `Confidential` when used to discuss customer data, security findings, or personnel matters. Public channels within the workspace are `Restricted`. Community Slack channels open to non-employees are `Public`. - Issues, pull requests, and tickets in private repositories are `Restricted` by default and `Confidential` when they contain customer data or security findings. Security findings shall use private security advisories rather than open issues. - Email carrying Confidential information shall state the classification in the subject line or the first line of the body. ### 2.5 Physical records Confidential information printed to paper shall be labelled "Confidential" on every page, shall only be produced where there is a genuine business need, and shall be stored and destroyed in accordance with the Data Management Policy. ## 3. Handling labels through the information lifecycle - **Derivation.** Any copy, extract, summary, screenshot, or export of labelled information inherits the label of its source. Removing context does not lower the class. - **Reclassification.** Information may be reclassified downward only by the data owner, and only once the sensitivity that justified the original class no longer applies. Reclassification of Confidential information shall be recorded with who approved it and why. - **Publication.** Moving information to `Public` is a deliberate act requiring data owner approval. Publishing customer data, security findings, or personal data requires the affected party's consent or a documented legal basis. - **Disposal.** Labelled information shall be disposed of in accordance with the retention and disposal requirements of the Data Management Policy. ## 4. Verification - Labelling is checked as part of the annual review of the Data Management Policy and this policy. - Access reviews under the [Access control policy](/security/access-and-risk-management/access-control-policy) shall confirm that access granted to a system is consistent with the classification of the data that system holds. - Automated secret scanning runs in continuous integration against the main repository, on every pull request and on every merge to the default branch, so that Confidential authentication material committed in error is detected. Detections are handled under the [Incident Response Management](/security/human-and-incident-management/incident-response-management) policy. - Mislabelled or unlabelled information found by anyone shall be reported to the data owner and corrected. Discovery of Confidential information in a Public location is a security incident. ## 5. Training Classification and labelling are covered in security onboarding and in the annual security awareness refresher. Personnel are expected to know the three classes, the default class, and the criteria that make information Confidential. ## Roles and responsibilities **Security lead.** Owns this policy and the classification scheme, resolves escalated classification disputes, approves reclassification of Confidential information. **Data owners.** Classify the information in their systems and business areas, approve reclassification and publication, and confirm labelling during reviews. **All personnel.** Classify what they create at the point of creation, apply the correct label, honour the handling requirements of the label, and report labelling errors they find. ## Exceptions Requests for an exception to this policy must be submitted to the IT Manager for approval and shall be reviewed at least annually. ## Violations and enforcement Any known violations of this policy should be reported to the IT Manager. Violations can result in immediate withdrawal or suspension of system and network privileges and disciplinary action in accordance with company procedures up to and including termination of employment. ## Review This policy shall be reviewed annually, or whenever the classification scheme in the Data Management Policy changes. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/business-continuity-and-data-protection/data-loss-prevention" LLMS_URL: "/security/business-continuity-and-data-protection/data-loss-prevention.md" title: "Data-loss prevention" titleTemplate: ":title | Business continuity and data protection | Security | Tuist Handbook" description: "This page outlines the strategies and mechanisms Tuist employs to prevent data loss, ensuring the security and continuity of company operations." --- # Data-loss prevention - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** December 23rd, 2024 ## Purpose The purpose of this policy is to outline the mechanisms and strategies Tuist has implemented to prevent data loss and ensure the security of company and project information. These measures are designed to minimize risks associated with unauthorized access, accidental loss, or data breaches, and to maintain business continuity and compliance with security standards. ## Scope This policy applies to all Tuist employees, contractors, and any other individuals with access to Tuist's systems, devices, or data. It covers both physical and digital environments, including remote workstations and company-managed devices. ## Mechanisms ### 1. Disabling Cloud-Storage Solutions To prevent the unauthorized transfer of company data to third-party cloud services: - iCloud and other cloud-storage solutions are disabled on remote workstations through Mobile Device Management (MDM). - This ensures that sensitive company data remains within approved and monitored storage systems. ### 2. Restriction on Removable Storage Devices To prevent data exfiltration via physical media: - The use of removable storage devices, such as USB drives and external hard drives, is disabled on all company-managed devices. - Exceptions can only be granted by the policy owner following a thorough review and approval process. ## Planned Improvements As part of our ongoing commitment to enhancing data-loss prevention, we aim to roll out advanced Data Loss Prevention (DLP) solutions in the following areas by H2 2025: - **Email Systems:** Implementing DLP mechanisms to monitor and control the transmission of sensitive information via email. ## Roles and Responsibilities - **Policy Owner:** Responsible for overseeing the implementation and adherence to the data-loss prevention mechanisms. - **Employees and Contractors:** Must comply with this policy and report any attempts to bypass these measures. - **IT Team:** Ensures proper configuration and enforcement of the outlined mechanisms. ## Monitoring and Enforcement - Regular audits are conducted to ensure compliance with the policy. - Any violations of this policy will be subject to investigation and may result in disciplinary actions, up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/business-continuity-and-data-protection/network-traffic-management-policy" LLMS_URL: "/security/business-continuity-and-data-protection/network-traffic-management-policy.md" title: "Network traffic management policy" titleTemplate: ":title | Business continuity and data protection | Security | Tuist Handbook" description: "This policy establishes procedures for monitoring, controlling, managing, and evaluating network traffic to identify vulnerabilities, anomalies and capacity issues in Tuist GmbH's infrastructure." --- # Network traffic management policy - **Policy owner:** Pedro Piñera Buendía - **Effective date:** December 12, 2024 ## Purpose To establish comprehensive rules and procedures for monitoring, controlling, managing, and periodically evaluating network traffic to identify vulnerabilities, anomalies, and capacity issues to protect Tuist GmbH's applications and services. ## Scope This policy applies to all network traffic related to Tuist GmbH applications and services, while recognizing the shared responsibility model with our infrastructure and edge providers as documented in our [Shared Responsibility Model](/security/shared-responsibility-model). ## Shared Responsibility Model for Network Traffic Management Tuist GmbH operates its services on managed cloud infrastructure and behind a managed edge network, which creates a shared responsibility model for network traffic management: ### Infrastructure and edge provider responsibilities: - Physical network infrastructure security - Network perimeter security including DDoS protection at the edge - Core network monitoring and management - Underlying network capacity planning - Network-level intrusion detection and prevention ### Tuist GmbH responsibilities: - Cluster-level network policy, segmentation, and egress control - Configuration of edge controls, including web application firewall rules, bot mitigation, and TLS termination settings - Application-level traffic monitoring and analysis - API request monitoring and rate limiting - Application-generated network traffic patterns - Identifying and responding to application-level traffic anomalies - Implementing proper access controls for application endpoints ## Policy Requirements ### 1. Traffic Monitoring and Analysis - **Regular Monitoring**: Tuist GmbH shall implement and maintain tools to monitor application-level network traffic at least daily. - **Logging Requirements**: All application-level network traffic shall be logged with timestamps, source/destination information, request types, response codes, and data volumes. - **Automated Alerts**: Automated monitoring systems shall be configured to alert the operations team when: - Unusual traffic patterns are detected - Error rates exceed defined thresholds - Application response times degrade beyond acceptable levels - Traffic volumes approach capacity limits ### 2. Traffic Control and Management - **Rate Limiting**: All public-facing APIs shall implement appropriate rate limiting to prevent abuse. - **Access Controls**: Network traffic shall be restricted based on the principle of least privilege. - **Traffic Prioritization**: - Business-critical traffic must be prioritized to ensure smooth operations. - Non-essential traffic may be restricted during high-demand periods. - **Traffic Filtering**: Application-level traffic filtering shall be implemented to prevent known attack patterns. ### 3. Periodic Evaluation and Assessment - **Regular Reviews**: Tuist GmbH shall conduct formal reviews of network traffic patterns at least quarterly to identify trends, anomalies, and potential security issues. - **Capacity Planning**: Traffic volume trends shall be analyzed at least quarterly to ensure adequate capacity planning. - **Vulnerability Scanning**: Application vulnerability scanning shall be performed at least quarterly to identify potential security weaknesses. - **Annual Assessment**: A comprehensive assessment of network traffic management controls shall be performed annually, including: - Effectiveness of monitoring tools - Adequacy of alerting thresholds - Review of incident response times - Analysis of traffic patterns and anomalies - Evaluation of capacity planning forecasts ### 4. Anomaly Detection and Response - **Baseline Establishment**: Normal traffic patterns shall be established and documented as baselines. - **Deviation Thresholds**: Acceptable deviation thresholds from baselines shall be defined and documented. - **Incident Response**: Anomalous traffic that exceeds defined thresholds shall trigger the incident response procedure as defined in the [Incident Response Management](/security/human-and-incident-management/incident-response-management) policy. - **Documentation**: All detected anomalies, their investigations, and resolutions shall be documented. ### 5. Security Controls for Network Traffic - **Encryption**: All network traffic shall be encrypted in transit using industry-standard protocols. - **Authentication**: Access to Tuist GmbH services shall require appropriate authentication. - **Secure API Design**: APIs shall be designed with security best practices to prevent common vulnerabilities. - **Regular Security Updates**: Security patches for application components shall be applied according to the vulnerability management requirements in the [Secure Development Policy](/security/secure-development-and-operations/secure-development-policy). ### 6. Threat Detection and Mitigation Tooling Tuist GmbH shall implement and maintain the following categories of control to detect and mitigate network-borne threats. Where a control is delivered by a provider under the shared responsibility model, Tuist GmbH remains responsible for its configuration and for reviewing its output. - **Firewalls.** Perimeter filtering is provided by the edge network and by cloud provider firewall rules. In-cluster segmentation is enforced through network policies so that workloads can only reach the services they require. Default-deny is the baseline; every allowed path is explicit. - **Web application firewall.** A managed WAF sits in front of all public endpoints, filtering known attack patterns including injection, traversal, and common bot traffic. Rule sets are kept current and exclusions are documented. - **Intrusion detection.** Provider-level network intrusion detection covers the underlying infrastructure. At the application layer, Tuist GmbH detects intrusion attempts through authentication anomaly alerting, rate limit breach alerting, and log-based detection rules maintained under the [Logging and Monitoring Policy](/security/secure-development-and-operations/logging-and-monitoring-policy). - **Intrusion prevention.** Detected malicious traffic is blocked inline through edge rules, rate limiting, and IP or account-level blocking. Blocking actions taken automatically shall be reviewed so that legitimate traffic caught by a rule is identified and the rule adjusted. - **DDoS protection.** Volumetric and protocol-level attack mitigation is provided at the edge and is enabled for all public endpoints. ### 7. Monitoring Tools and Technologies Tuist GmbH shall implement and maintain at least the following monitoring tools: - Application Performance Monitoring (APM) solutions - API gateway monitoring and analytics - Log aggregation and analysis tools - Real-time alerting systems - Traffic visualization dashboards ### 8. Documentation and Reporting - **Traffic Reports**: Monthly network traffic summary reports shall be generated and reviewed by IT management. - **Incident Documentation**: All traffic-related security incidents shall be documented according to the Incident Response Management policy. - **Trend Analysis**: Quarterly trend analysis reports shall be generated to identify long-term patterns. - **Annual Assessment Report**: An annual comprehensive assessment of network traffic management shall be documented. ## Implementation and Evidence of Compliance To demonstrate compliance with this policy, Tuist GmbH shall maintain the following evidence: 1. Screenshots of monitoring dashboards showing active traffic monitoring 2. Logs of detected anomalies and their remediation 3. Quarterly network traffic analysis reports 4. Annual comprehensive network traffic assessment reports 5. Documentation of alerting thresholds and their review history 6. Minutes of capacity planning meetings 7. Evidence of regular security scanning and vulnerability testing 8. Incident response documentation for network-related security events ## Roles and Responsibilities ### IT Manager/Security Lead - Overall responsibility for implementation of this policy - Review of network traffic reports and assessments - Approval of changes to monitoring thresholds and alerting rules ### Development and Operations Teams - Day-to-day monitoring of application network traffic - Implementation of technical controls for traffic management - Initial investigation and response to traffic anomalies - Implementation of approved capacity improvements ## Compliance Any breach of this policy may result in disciplinary action up to and including termination of employment in accordance with company procedures. Non-compliance may also result in access restrictions or termination of network privileges. ## Review This policy shall be reviewed annually or when significant changes occur to Tuist's technology infrastructure. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/employee-termination-security-policy" LLMS_URL: "/security/employee-termination-security-policy.md" title: "Employee termination security policy" titleTemplate: ":title | Security | Tuist Handbook" description: "To ensure the secure handling of company assets and information upon employee termination, safeguarding both company and customer data. This policy establishes requirements for revoking access, returning assets, and protecting confidential information after an employee’s departure." --- # Employee termination security policy - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** 03.01.2025 ## Purpose This policy ensures the secure handling of company assets and information when an employee departs from Tuist GmbH. The policy defines procedures to mitigate any security risks associated with terminated employees, including the revocation of access, return of assets, and preservation of confidentiality. ## Scope This policy applies to all employees, contractors, and temporary workers who have been granted access to Tuist GmbH’s systems, data, and physical assets. ## General Requirements Upon termination of employment, Tuist GmbH shall: 1. **Revoke Access**: All access to company systems, networks, applications, and data shall be revoked immediately upon the termination of an employee’s contract. This includes the deactivation of all user accounts, password access, and physical keys. 2. **Return of Company Assets**: All company-owned equipment, including but not limited to laptops, mobile devices, access cards, and documents, shall be returned to the company in a timely manner. 3. **Data Security**: Any sensitive data in the possession of the terminated employee, whether stored physically or digitally, must be returned, deleted, or encrypted in accordance with company data protection procedures. 4. **Non-Disclosure and Confidentiality**: The terminated employee shall continue to be bound by any non-disclosure agreements (NDAs) and confidentiality commitments made during their employment. They must not disclose, distribute, or use confidential company or customer data. ## Procedures 1. **Revocation of Access**: - IT department shall revoke system access, including email accounts, cloud storage, internal databases, and third-party software services. - All physical access credentials (e.g., office keys, ID badges) shall be returned to HR or the security team. 2. **Exit Interviews**: - An exit interview should be conducted to remind the employee of their ongoing obligations regarding confidentiality and intellectual property protection. - Documentation of the termination process, including the return of assets and revocation of access, should be kept for auditing purposes. 3. **Documentation**: - All actions taken during the termination process should be documented in the employee’s termination file. - A signed acknowledgment of the return of assets and completion of security procedures should be obtained from the employee. ## Violations & Enforcement Any failure to comply with this policy may result in the following actions: - Immediate revocation of access to company systems. - Disciplinary action in accordance with Tuist GmbH's procedures, up to and including legal action for the breach of confidentiality or misuse of company data. ## Exceptions Requests for exceptions to this policy must be submitted in writing to the HR Manager and the IT Manager for review and approval. ## Version History The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/human-and-incident-management/human-resource-security-policy" LLMS_URL: "/security/human-and-incident-management/human-resource-security-policy.md" title: "Human resource security policy" titleTemplate: ":title | Human and incident management | Security | Tuist Handbook" description: "To ensure that personnel and contractors meet security requirements, understand their responsibilities, and are suitable for their roles." --- # Human resource security policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To ensure that personnel and contractors meet security requirements, understand their responsibilities, and are suitable for their roles. ## Scope This policy applies to all employees of Tuist GmbH, consultants, contractors and other third-party entities with access to Tuist GmbH production networks and system resources. ## Screening Background verification checks on Tuist GmbH personnel shall be carried out in accordance with relevant laws, regulations, and shall be proportional to the business requirements, the classification of the information to be accessed, and the perceived risks. Background screening shall include criminal history checks unless prohibited by local statute. All third- parties with technical privileged or administrative access to Tuist GmbH production systems or networks are subject to a background check or requirement to provide evidence of an acceptable background, based on their level of access and the perceived risk to Tuist GmbH. ## Competence & performance assessment The skills and competence of employees and contractors shall be assessed by human resources staff and the hiring manager or his or her designees as part of the hiring process. Required skills and competencies shall be listed in job descriptions and requisitions, and/or aligned with the responsibilities outlined in the Information Security Roles and Responsibilities Policy. Competency evaluations may include reference checks, education and certification verifications, technical testing, and interviews. All Tuist GmbH employees will undergo an annual performance review which will include an assessment of job performance, competence in the role, adherence to company policies and code of conduct, and achievement of role-specific objectives. ## Terms & conditions of employment Company policies and information security roles and responsibilities shall be communicated to employees and third-parties at the time of hire or engagement, and employees and contractors are required to formally acknowledge their understanding and acceptance of their security responsibilities. Employees and third-parties with access to company or customer information shall sign an appropriate non-disclosure, confidentiality, and appropriate code-of-conduct agreements. Contractual agreements shall state responsibilities for information security as needed. Employees and relevant third-parties shall follow all Tuist GmbH information security policies. ## Management responsibilities Management shall be responsible for ensuring that information security policies and procedures are reviewed annually, distributed and available, and that personnel and contractors abide by those policies and procedures for the duration of their employment or engagement. Annual policy review shall include a review of any linked or referenced procedures, standards or guidelines. Management shall ensure that information security responsibilities are communicated to individuals, through written job descriptions, policies or some other documented method which is accurately updated and maintained. Compliance with information security policies and procedures and fulfillment of information security responsibilities shall be evaluated as part of the performance review process wherever applicable. Management shall consider excessive pressures, and opportunities for fraud when establishing incentives and segregating roles, responsibilities, and authorities. ## Information Security awareness, education & training All Tuist GmbH employees and third-parties with administrative or privileged technical access to Tuist GmbH production systems and networks shall complete security awareness training at the time of hire and annually thereafter. Management shall monitor training completion and shall take appropriate steps to ensure compliance with this policy. Employees and contractors shall be aware of relevant information security and data privacy policies and procedures. The company shall ensure that personnel receive security and data privacy training appropriate to their role and data handling responsibilities. In order to maintain a robust level of security awareness, the company will provide security-related updates and communications to company personnel on an on-going basis through multiple communication channels as needed. Information security leaders and managers shall ensure appropriate professional development occurs to provide an understanding of current threats and trends in the security landscape. Security leaders and key stakeholders shall attend trainings, obtain and maintain relevant certifications, and maintain memberships in industry groups as appropriate. ## Termination process Employee and contractor termination and offboarding processes shall ensure that physical and logical access is promptly revoked in accordance with company SLAs and policies, and that all company issued equipment is returned. Any security or confidentiality agreements which remain valid after termination shall be communicated to the employee or contractor at time of termination. ## Disciplinary process Employees and third-parties who violate Tuist GmbH information security policies shall be subject to the Tuist GmbH progressive disciplinary process, up to and including termination of employment or contract. ## Exceptions Requests for an exception to this policy must be submitted to the CEO for approval. ## Violations & enforcement Any known violations of this policy should be reported to the CEO. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company policies up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/human-and-incident-management/incident-response-management" LLMS_URL: "/security/human-and-incident-management/incident-response-management.md" title: "Incident response management" titleTemplate: ":title | Human and incident management | Security | Tuist Handbook" description: "Incident response management is a set of procedures that an organization follows when an incident occurs. The goal is to minimize the damage and reduce recovery time and costs." --- # Incident response management - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Contact information In case of an incident, urgently report it to [contact@tuist.dev](mailto:contact@tuist.dev). The incident response team will take it from there. ## Vulnerability remediation SLAs To ensure a swift and effective response to vulnerabilities, we have established the following SLAs for remediation based on severity: - **Critical Vulnerabilities:** These vulnerabilities are addressed within **24 hours** of identification. Immediate action is taken to mitigate risks that could significantly impact systems, users, or data. - **High Vulnerabilities:** These vulnerabilities are addressed within **72 hours** of identification. Prompt action is taken to reduce the likelihood of exploitation. These timelines are integrated into our incident response process to ensure timely remediation and minimize potential risks. ## Plan You can find the incident response plan in the [Incident Response Plan](/pdfs/security/human-and-incident-management/incident-response-plan-bsi.pdf) document. --- URL: "/security/information-security-framework/information-security-policy" LLMS_URL: "/security/information-security-framework/information-security-policy.md" title: "Information Security Policy (AUP)" titleTemplate: ":title | Information security framework | Security | Tuist Handbook" description: "The purpose of this policy is to communicate our information security policies and outline the acceptable use and protection of the company’s information and assets." --- # Information Security Policy (AUP) - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Overview This Information Security Policy is intended to protect Tuist GmbH's employees, partners and the company from illegal or damaging actions by individuals, either knowingly or unknowingly. Internet/Intranet/Extranet-related systems, including but not limited to computer equipment, software, operating systems, storage media, network accounts providing electronic mail, web browsing, and file transfers, are the property of Tuist GmbH. These systems are to be used for business purposes in serving the interests of the company, and of our clients and customers in the course of normal operations. Effective security is a team effort involving the participation and support of every Tuist GmbH employee or contractor who deals with information and/or information systems. It is the responsibility of every team member to read and understand this policy, and to conduct their activities accordingly. ## Purpose The purpose of this policy is to communicate our information security policies and outline the acceptable use and protection of Tuist GmbH's information and assets. These rules are in place to protect customers, employees, and Tuist GmbH. Inappropriate use exposes Tuist GmbH to risks including virus attacks, compromise of network systems and services, and legal and compliance issues. The Tuist GmbH “Information Security Policy” is comprised of this policy and all Tuist GmbH policies referenced and/or linked within this document. ## Scope This policy applies to the use of information, electronic and computing devices, and network resources to conduct Tuist GmbH business or interact with internal networks and business systems, whether owned or leased by Tuist GmbH, the employee, or a third party. All employees, contractors, consultants, temporary, and other workers at Tuist GmbH and its subsidiaries are responsible for exercising good judgment regarding appropriate use of information, electronic devices, and network resources in accordance with Tuist GmbH policies and standards, and local laws and regulations. This policy applies to employees, contractors, consultants, temporaries, and other workers at Tuist GmbH, including all personnel affiliated with third parties. This policy applies to all Tuist GmbH-controlled company and customer data as well as all equipment, systems, networks and software owned or leased by Tuist GmbH. ## Security incident reporting All users are required to report known or suspected security events or incidents, including policy violations and observed security weaknesses. Incidents shall be reported immediately or as soon as possible by sending email to [contact@tuist.dev](mailto:contact@tuist.dev). In your report, please describe the incident or observation along with any relevant details. ## Whistleblower anonymous fraud reporting Our Whistleblower Policy is intended to encourage and enable employees and others to raise serious concerns internally so that we can address and correct inappropriate conduct and actions. It is the responsibility of all employees to report concerns about violations of our code of ethics or suspected violations of law or regulations that govern our operations. It is contrary to our values for anyone to retaliate against any employee or who in good faith reports an ethics violation, or a suspected violation of law, such as a complaint of discrimination, or suspected fraud, or suspected violation of any regulation. An employee who retaliates against someone who has reported a violation in good faith is subject to discipline up to and including termination of employment. Anonymous reports may be submitted via https://opnform.com/forms/my-form-r0muos. ## Mobile device policy All end-user devices (e.g., mobile phones, tablets, laptops, desktops) must comply with this policy. Employees must use extreme caution when opening email attachments received from unknown senders, which may contain malware. System level and user level passwords must comply with the Access Control Policy. Providing access to another individual, either deliberately or through failure to secure a device is prohibited. All end-user, personal (BYOD) or company owned devices used to access Tuist GmbH information systems (i.e. email) must adhere to the following rules and requirements: - Devices must be locked with a password (or equivalent control such as biometric) protected screensaver or screen lock after 5 minutes of non-use - Devices must be locked whenever left unattended - Users must report any suspected misuse or theft of a mobile device immediately to the CEO - Confidential information must not be stored on mobile devices or USB drives (this does not apply to business contact information, e.g., names, phone numbers, and email addresses) - Any mobile device used to access company resources (such as file shares and email) must not be shared with any other person - Upon termination users agree to return all company owned devices and delete all company information and accounts from any personal devices ## Clear screen clear desk policy Users shall not leave confidential materials unsecured on their desk or workspace, and will ensure that screens are locked when not in use. ## Remote working and access policy Remote working refers to any situation where organizational personnel operate from locations outside the office. This includes teleworking, telecommuting, flexible workplace, virtual work environments, and remote maintenance. Laptops and other computer resources that are used to access the Tuist GmbH network must conform to the security requirements outlined in Tuist GmbH's Information Security Policies and adhere to the following standards: - Company rules shall be followed while working remote including clear desk protocols, printing, disposal of assets, and information security event reporting to prevent mishandling or accidental exposure of sensitive information. - Mandate the use of VPN when transmitting confidential information over public Wi-Fi to prevent potential eavesdropping or man-in-the-middle attacks. - For system administrator, it is advised to set up a work specific network with strong WPA3 encryption or at least WPA2 with Robust password, together with, if supported, setting up a dedicated VLAN. Additionally, WPS (Wi-Fi Protected Setup) and UPnP (Universal Plug and Play) should be disabled if not specifically required. - To ensure mobile devices do not connect a compromised device to the company network, Antivirus policies require the use and enforcement of client-side antivirus software - Antivirus software must be configured to detect and prevent or quarantine malicious software, perform periodic system scans, and have automatic updates enabled - When working from a home network, ensure that the default wifi settings are changed, such as name, password and admin access - Users must not connect to any outside network without a secure, up-to-date software firewall configured on the mobile computer - Users are prohibited from changing or disabling any organizational security controls such as personal firewalls, antivirus software on systems used to access Tuist GmbH resources - Use of remote access software and/or services (e.g., VPN client) is allowable as long as it is provided by the company and configured for multifactor authentication (MFA) - Unauthorized remote access technologies may not be used or installed on any Tuist GmbH system - Users shall use a VPN when transmitting confidential information on public Wi-Fi - If you access from a public computer (e.g., from a business center, hotel, etc.), log out of the session and don't save anything. Don't check “remember me”, collect all printed materials and do not download files to a non-Tuist GmbH controlled system. ## Acceptable Use Policy Tuist GmbH proprietary and customer information stored on electronic and computing devices, whether owned or leased by Tuist GmbH, the employee, or a third party, remains the sole property of Tuist GmbH for the purposes of this policy. Employees and contractors must ensure through legal or technical means that proprietary information is protected in accordance with the Data Management Policy. The use of [NextCloud](https://storage.tuist.io) for business file storage is required for users of laptops or company-issued devices. Storing important documents on the file share serves as the "backup" for your laptop. Employees and contractors must use Tuist GmbH systems only for authorized purposes. You may access, use, or share Tuist GmbH proprietary information only to the extent it is authorized and necessary to fulfill your assigned job duties. Proprietary information must be protected according to the Data Management Policy, and employees are prohibited from sharing this information without proper authorization, both during and after employment. Upon termination of employment, all company-owned devices must be returned, and all company data and accounts must be removed from personal devices. You have a responsibility to promptly report the theft, loss, or unauthorized disclosure of Tuist GmbH proprietary information or equipment. Employees are responsible for exercising good judgment regarding the reasonableness of personal use of company-provided devices. For security and network maintenance purposes, authorized individuals within Tuist GmbH may monitor equipment, systems, and network traffic at any time. Tuist GmbH reserves the right to audit networks and systems periodically to ensure compliance with this policy. ## Unacceptable Use The following activities are prohibited. Employees may be exempted from these restrictions during legitimate job responsibilities with properly documented Management approval. Under no circumstances is an employee of Tuist GmbH authorized to engage in illegal activities under local, state, federal, or international law while utilizing Tuist GmbH-owned resources or while representing Tuist GmbH in any capacity. The following activities are strictly prohibited, with no exceptions: 1. Violating the rights of any person or company protected by copyright, trade secret, patent, or other intellectual property laws, including the installation or distribution of pirated or unlicensed software 2. Copying copyrighted material without authorization, including but not limited to, digitization and distribution of media or software not licensed for use by Tuist GmbH 3. Accessing data, servers, or accounts without proper authorization or for purposes other than conducting Tuist GmbH business 4. Exporting software, technical information, encryption software, or technology in violation of export control laws 5. Introducing malicious programs into the network or systems (e.g., viruses, worms, Trojan horses, etc.) 6. Sharing account passwords or allowing unauthorized use of accounts, including by family or household members 7. Using Tuist GmbH systems to engage in activities violating sexual harassment or hostile workplace laws 8. Making fraudulent offers of products, services, or warranties 9. Engaging in unauthorized security breaches or disruptions of network communication, including denial of service attacks or unauthorized monitoring 10. Circumventing security measures or introducing unauthorized systems or devices (e.g., honeypots) 11. Providing information about Tuist GmbH employees, contractors, partners, or customers without proper authorization 12. Failing to remove proprietary information or accounts from personal devices upon termination of employment. ## Email and communication activities When using company resources to access and use the Internet, users must realize they represent the company and act accordingly. The following activities are strictly prohibited, with no exceptions: 1. Sending unsolicited email messages, including the sending of "junk mail", or other advertising material to individuals who did not specifically request such material (email spam) 2. Any form of harassment via email, telephone, or texting, whether through language, frequency, or size of messages 3. Unauthorized use, or forging, of email header information 4. Solicitation of email for any other email address, other than that of the poster's account, with the intent to harass or to collect replies 5. Creating or forwarding "chain letters", "Ponzi", or other "pyramid" schemes of any type 6. Use of unsolicited email originating from within Tuist GmbH networks or other service providers on behalf of, or to advertise, any service hosted by Tuist GmbH or connected via Tuist GmbH's network ## Additional policies and procedures incorporated by reference | Policy | Purpose | |---------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| | Access Control Policy | To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives. | | Asset Management Policy | To identify organizational assets and define appropriate protection responsibilities. | | Business Continuity & Disaster Recovery Plan | To prepare Tuist GmbH in the event of extended service outages caused by factors beyond our control (e.g., natural disasters, man-made events), and to restore services to the widest extent possible in a minimum time frame. | | Cryptography Policy | To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information. | | Data Management Policy | To ensure that information is classified and protected in accordance with its importance to the organization. | | Human Resources Policy | To ensure that employees and contractors meet security requirements, understand their responsibilities, and are suitable for their roles. | | Incident Response Plan | Policy and procedures for suspected or confirmed information security incidents. | | Operations Security Policy | To ensure the correct and secure operation of information processing systems and facilities. | | Physical Security Policy | To prevent unauthorized physical access or damage to the organization’s information and information processing facilities. | | Risk Management Policy | To define the process for assessing and managing Tuist GmbH's information security risks in order to achieve the company’s business and information security objectives. | | Secure Development Policy | To ensure that information security is designed and implemented within the development lifecycle for applications and information systems. | ## Policy compliance The organization will measure and verify compliance to this policy through various methods, including but not limited to ongoing monitoring, and both internal and external audits. ## Exceptions Requests for an exception to this policy must be submitted to the CEO for approval. ## Violations & enforcement Any known violations of this policy should be reported to the CEO. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/information-security-framework/information-security-roles-and-responsibilities" LLMS_URL: "/security/information-security-framework/information-security-roles-and-responsibilities.md" title: "Information Security Roles and Responsibilities" titleTemplate: ":title | Information security framework | Security | Tuist Handbook" description: "This document outlines the roles and responsibilities within Tuist GmbH, which is critical for effective communication of information security policies and standards." --- # Information Security Roles and Responsibilities - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Statement of policy Tuist GmbH is committed to conducting business in compliance with all applicable laws, regulations, and company policies. Tuist GmbH has adopted this policy to outline the security measures required to protect electronic information systems and related equipment from unauthorized use. ## Objective This policy and associated guidance establish the roles and responsibilities within Tuist GmbH, which is critical for effective communication of information security policies and standards. Roles are required within the organization to provide clearly defined responsibilities and an understanding of how the protection of information is to be accomplished. Their purpose is to clarify, coordinate activity, and actions necessary to disseminate security policy, standards, and implementation. ## Applicability This policy is applicable to all Tuist GmbH infrastructure, network segments, systems, and employees and contractors who provide security and IT functions. ## Audience The audience for this policy includes all Tuist GmbH employees and contractors who are involved with the Information Security Program. Awareness of this policy applies for all other agents of Tuist GmbH with access to Tuist GmbH information and infrastructure. This includes, but is not limited to partners, affiliates, contractors, temporary employees, trainees, guests, and volunteers. The titles will be referred collectively hereafter as “Tuist GmbH community”. ## Roles and responsibilities | **Roles** | **Responsibilities** | |-----------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Board of Directors** | - Oversight of Cyber-Risk and internal control for information security, privacy and compliance.
- Consults with Executive Leadership to understand Tuist GmbH IT mission and risks and provides guidance to align business, IT, and security objectives. | | **Executive Leadership** | - Approves Capital Expenditures for Information Security and Privacy programs and initiatives.
- Oversight over the execution of the information security and Privacy risk management program and risk treatments.
- Communication Path to Tuist GmbH Board of Directors.
- Aligns Information Security and Privacy Policy and Posture based on Tuist GmbH's mission, strategic objectives and risk appetite. | | **IT Manager** | - Oversight over the implementation of information security controls for infrastructure and IT processes.
- Responsible for the design, development, implementation, operation, maintenance and monitoring of IT security controls.
- Ensures IT puts into practice the Information Security Framework.
- Responsible for conducting IT risk assessments, documenting identified threats and maintaining risk register.
- Communicates information security risks to executive leadership.
- Reports information security risks annually to Tuist GmbH's leadership and gains approvals to bring risks to acceptable levels.
- Coordinates the development and maintenance of information security policies and standards.
- Works with applicable executive leadership to establish an information security framework and awareness program.
- Serve as liaison to the Board of Directors, Law Enforcement, Internal Audit and General Counsel.
- Oversight over Identity Management and Access Control processes. | | **VP of Engineering** | - Oversight over information security in the software development process.
- Responsible for the design, development, implementation, operation, maintenance and monitoring of development and commercial cloud hosting security controls.
- Responsible for oversight over policy development related to systems and software under their control.
- Responsible for implementing risk management in the development process aligned with company goals. | | **Compliance Manager** | - Responsible for compliance with the company's contractual commitments.
- Responsible for maintaining compliance with relevant data privacy and information security laws and regulations (e.g. GDPR, CCPA).
- Responsible for adherence to company adopted information security and data privacy standards and frameworks including SOC 2, ISO 27001 and Microsoft Supplier Data Protection Requirements (DPR). | | **VP of Global Customer Support** | - Oversight and implementation, operation and monitoring of information security tools and processes in customer production environments.
- Execution of customer data retention and deletion processes in accordance with company policy and customer requirements. | | **Systems Owners** | - Maintain the confidentiality, integrity and availability of the information systems for which they are responsible in compliance with Tuist GmbH policies on information security and privacy.
- Approval of technical access and change requests for non-standard access to systems under their control. | | **Employees, Contractors, temporary workers, etc.** | - Acting at all times in a manner which does not place at risk the health and safety of themselves, other person in the workplace, and the information and resources they have use of.
- Helping to identify areas where risk management practices should be adopted.
- Taking all practical steps to minimize Tuist GmbH's exposure to contractual and regulatory liability.
- Adhering to company policies and standards of conduct.
- Reporting incidents and observed anomalies or weaknesses. | ## Policy compliance The IT Manager will measure the compliance to this policy through various methods, including, but not limited to—reports, internal/external audits, and feedback to the policy owner. Exceptions to the policy must be approved by the IT Manager in advance. Non-compliance will be addressed with management and Human Resources and can result in disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/physical-and-asset-security/asset-management-policy" LLMS_URL: "/security/physical-and-asset-security/asset-management-policy.md" title: "Asset management policy" titleTemplate: ":title | Physical and asset security | Security | Tuist Handbook" description: "To identify organizational assets and define appropriate protection responsibilities. To ensure that information receives an appropriate level of protection in accordance with its importance to the organization. To prevent unauthorized disclosure, modification, removal, or destruction of information stored on media.." --- # Asset Management Policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To identify organizational assets and define appropriate protection responsibilities. To ensure that information receives an appropriate level of protection in accordance with its importance to the organization. To prevent unauthorized disclosure, modification, removal, or destruction of information stored on media. ## Scope This policy applies to all Tuist GmbH owned or managed information systems. ## Inventory of assets Assets associated with information and information processing facilities that store, process, or transmit classified information shall be identified and an inventory of these assets shall be created and maintained. ## Ownership of assets Assets maintained in the inventory shall be owned by a specific individual or group within Tuist GmbH. ## Acceptable use of assets Rules for the acceptable use of information, assets, and information processing facilities shall be identified and documented in the [Information Security Policy](/security/information-security-framework/information-security-policy). ## Loss or theft of assets All Tuist GmbH personnel must immediately report the loss of any information systems, including portable or laptop computers, smartphones, PDAs, authentication tokens (keyfobs, one-time-password generators, or personally owned smartphones or devices with a Tuist GmbH software authentication token installed) or other devices that can store and process or help grant access to Tuist GmbH data. ## Return of assets All personnel and third-party users of Tuist GmbH equipment shall return all of the organizational assets within their possession upon termination of their employment, contract, or agreement. ## Handling of assets Employees and users who are issued or handle Tuist GmbH equipment are expected to use reasonable judgment and exercise due care in protecting and maintaining the equipment. Employees are responsible for ensuring that company equipment is secured and properly attended to whenever it is transported or stored outside of company facilities. All mobile devices shall be handled in accordance with the [Information Security Policy](/security/information-security-framework/information-security-policy). Excepting employee-issued devices, no company computer equipment or devices may be moved or taken off-site without appropriate authorization from management. ## Asset disposal & reuse Company devices and media that stored or processed confidential data shall be securely disposed of when no longer needed. Data must be erased prior to disposal or reuse, using an approved technology in order to ensure that data is not recoverable. Or a Certificate of Destruction (COD) must be obtained for devices destroyed by a third-party service. Please refer to [NIST Special Publication 800-88 Revision 1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf) "Guidelines for Media Sanitization" in order to select which methods are appropriate. ## Customer asset return Any physical assets owned by customers shall be promptly returned to the customer following service termination in accordance with the terms of contract or service agreement. ## Exceptions Requests for an exception to this policy must be submitted to the IT Manager for approval. ## Violations & enforcement Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/physical-and-asset-security/physical-security-policy" LLMS_URL: "/security/physical-and-asset-security/physical-security-policy.md" title: "Physical security policy" titleTemplate: ":title | Physical and asset security | Security | Tuist Handbook" description: "To prevent unauthorized physical access or damage to the organization's information and information processing facilities." --- # Physical security policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To prevent unauthorized physical access or damage to the organization's information and information processing facilities. ## Scope All Tuist GmbH offices and locations. This Policy applies to all employees of Tuist GmbH, and to all external parties with physical access to Tuist GmbH owned or leased facilities. ## Physical security perimeter Physical offices and processing facilities shall meet all local building codes for construction materials for walls, windows, doors, and access control mechanisms. Some interior zones may be identified as secure areas where physical access is further restricted to a subset of Tuist GmbH personnel; such as private offices, wiring closets, print and server rooms, and server racks. ## Physical entry controls Secure areas shall be protected by appropriate entry controls to ensure that only authorized personnel are allowed access. Where possible, Tuist GmbH access control systems shall be tied to a centralized system that provides granular access control for individual personnel. Access events shall be appropriately logged and reviewed as needed according to risk. Cameras and intrusion detection systems shall be used at facilities that store or process production or sensitive internal company data. ## Securing offices, rooms & facilities Physical security for offices, rooms and facilities shall be designed and applied to protect from theft, misuse, environmental threats, unauthorized access, and other threats to the confidentiality, integrity, and availability of classified data and systems. ## Protecting against external & environmental threats Physical protection against natural disasters, malicious attack or accidents shall be designed and applied. Secure areas shall be monitored through the use of appropriate controls, such as intrusion detection systems, alarms, and/or video surveillance systems, where feasible. Visitor and third-party access to secure areas shall be restricted to reduce the risk of information loss and theft. Production processing facilities shall be equipped with appropriate environmental and business continuity controls including fire-suppression systems, climate control and monitoring systems, and emergency backup power systems. Physical information system hardware and supporting infrastructure shall be regularly serviced and maintained in accordance with the manufacturer's recommendations. ## Working in secure areas / visitor management Visitors, delivery personnel, outside support technicians, and other external agents shall not be permitted access to secure areas without escort and/or appropriate oversight. Third-parties in secure areas shall sign in and out on a visitor log and shall be escorted or monitored by Tuist GmbH personnel. Tuist GmbH personnel observing unescorted visitors should approach the visitor, confirm their status, and ensure they return to approved areas, or report the observation to the responsible authority as needed. External party access to secure areas shall be confirmed with appropriate Tuist GmbH personnel prior to being granted access. Tuist GmbH personnel providing access to external parties into secure areas are responsible for ensuring that the third-party personnel adhere to all security requirements, and are accountable for all actions taken by outsiders they provide with access. Visitors may be allowed to work unescorted provided that the Tuist GmbH sponsoring party can ensure that they will not have unauthorized access to Tuist GmbH information systems, networks, or data. ## Delivery & loading areas Access points such as delivery and loading areas and other points where unauthorized persons could enter secure areas shall be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access. ## Supplier, vendor, and third-party security Suppliers, vendors, and third-parties shall comply with Tuist GmbH physical security and environmental controls requirements. Tuist GmbH shall assess the adequacy of third-party physical security controls as part of the vendor management process, in accordance with the *Third-Party Management Policy.* ## Exceptions Requests for an exception to this policy must be submitted to the IT Manager for approval. ## Violations & enforcement Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges an ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/secure-development-and-operations/logging-and-monitoring-policy" LLMS_URL: "/security/secure-development-and-operations/logging-and-monitoring-policy.md" title: "Logging and monitoring policy" titleTemplate: ":title | Secure development and operations | Security | Tuist Handbook" description: "This policy defines how Tuist GmbH logs user and system activity, what level of detail those logs carry, how logs are reviewed, and how log anomalies are responded to." --- # Logging and monitoring policy - **Policy owner:** Pedro Piñera Buendía - **Effective date:** August 14, 2026 ## Purpose To ensure that activity across Tuist GmbH systems and applications is logged at a level of detail that supports security investigations, business operations, and governance processes, that those logs are reviewed on a cadence proportionate to risk and information classification, and that anomalies found in logs are responded to in a manner appropriate to the risk they represent. ## Scope This policy applies to all Tuist GmbH production systems, internal systems, and third-party services that store, process, or transmit Confidential or Restricted data as defined in the [Data Management Policy](/pdfs/security/business-continuity-and-data-protection/data-management-policy-bsi.pdf). It applies to all employees, contractors, and third parties with access to those systems. Logging responsibility is shared with infrastructure providers, but not along the line a fully managed platform would draw. Tuist GmbH operates its own Kubernetes clusters and its own database on rented hardware, and buys managed services for object storage, edge delivery, and log storage. Providers are therefore responsible for logging at the physical and hardware layers and within the managed services they themselves run. Everything above that, including the cluster and platform layer as well as the application, data, and identity layers, is Tuist GmbH's responsibility. The [Shared Responsibility Model](/security/shared-responsibility-model) records the division per provider. ## 1. Logging requirements ### 1.1 Activity levels that must be logged Systems and applications shall log user activity at three levels: **Administrative activity.** Actions that change the security posture, configuration, or access model of a system: - Authentication events, including successful logins, failed login attempts, and multi-factor authentication challenges - Creation, modification, disabling, and deletion of user accounts and service accounts - Grants, changes, and revocations of roles, permissions, and privileged access - Elevation to privileged access, including the justification recorded at the time of elevation - Changes to infrastructure configuration, secrets, network rules, and deployment pipelines - Changes to logging and monitoring configuration itself **Application activity.** Actions users and services take inside Tuist GmbH products and internal tools: - Access to and modification of customer data and organization settings - Creation, rotation, and revocation of tokens, keys, and other credentials - Administrative operations performed by Tuist GmbH personnel on customer accounts, including impersonation sessions - Export or bulk retrieval of data - Errors and exceptions that indicate a security-relevant failure **Transaction activity.** Individual operations against data and service endpoints: - API requests, including method, endpoint, response status, and originating account - Database schema migrations and administrative queries executed outside the application - Object storage deletions of customer data, including those performed by scheduled retention and cleanup work. Reads and writes are not recorded at this level: artifact transfers are made directly against the storage provider using pre-signed URLs, so they never reach a Tuist GmbH server, and recording them would require provider-side access logging that is not enabled. The authorization decision that issued each pre-signed URL is recorded as a transaction level interface request. - Billing and subscription state changes ### 1.2 Minimum log content Each log record shall, where technically feasible, contain: - Timestamp in UTC - Identity of the actor: user ID, service account, or system component - Source of the request, such as IP address or workload identity - The action performed and the resource acted upon - The outcome of the action, including success or failure and any relevant error code - A correlation identifier that allows the record to be joined to related records across services Logs shall not contain secrets, credentials, full authentication tokens, or plaintext personal data beyond what is required to identify the actor and the affected resource. Where sensitive values must be recorded for traceability, they shall be redacted, hashed, or truncated. ### 1.3 Level of detail and governance alignment The level of logging detail shall be set so that it supports the business and governance processes that depend on it, specifically: - Security incident detection and investigation, as required by the [Incident Response Management](/security/human-and-incident-management/incident-response-management) policy - Access reviews and privileged access attestation, as required by the [Access control policy](/security/access-and-risk-management/access-control-policy) - Customer and regulatory data requests, including data subject access and deletion requests - Service reliability analysis and capacity planning - External audit and certification evidence Where a governance process requires evidence that current logging cannot produce, the logging configuration shall be extended rather than the process weakened. ### 1.4 Retention and integrity - Security-relevant logs shall be retained for a minimum of thirty (30) days, fully searchable for that period. Records of the log reviews described in section 2 are retained for at least one year, so the evidence of what was examined and what was found outlives the raw logs it was drawn from. - Because the retention window is thirty days, a review that is not performed on schedule cannot be performed retrospectively. Reviews scheduled monthly shall be completed within the first week of the period they cover. - Logs shall be shipped off the originating host to centralized storage so that compromise of a single system does not destroy its own audit trail. - Log storage shall be append-only or otherwise protected against modification and deletion by the accounts whose activity it records. - Access to logs shall follow the principle of least privilege and shall itself be logged. - Logs containing Confidential or Restricted data shall be encrypted in transit and at rest in accordance with the [Cryptography policy](/security/business-continuity-and-data-protection/cryptography-policy). ## 2. Log review Logs shall be reviewed periodically. Review frequency is driven by the risk of the system and the classification of the information it handles. | Log source | Information classification | Review frequency | | --- | --- | --- | | Production authentication and privileged access logs | Confidential | Monthly | | Production application and customer data access logs | Confidential | Monthly | | Infrastructure and deployment change logs | Confidential | Quarterly | | Third-party service administrative logs (identity provider, source control, cloud providers) | Confidential | Quarterly | | Internal tooling and collaboration systems | Restricted | Quarterly | | Public-facing marketing and documentation systems | Public | Annually | Reviews shall be performed by a person other than the primary operator of the system under review wherever staffing allows. At the current team size that separation is not achievable for most production systems, so where the reviewer is also an operator of a system under review, the review shall state that limitation explicitly alongside its findings. Naming the limitation in each record is what a reader needs in order to weigh the review, and it is a requirement this team can actually meet, which a second signature on every monthly review is not. Each review shall be recorded with the reviewer, the date, the period covered, the sources examined, and the findings. Records of reviews shall be retained for at least one year and serve as evidence of compliance. Continuous automated monitoring supplements but does not replace periodic review. Alerts that fire between reviews shall be triaged when they fire. ## 3. Anomaly detection and response ### 3.1 Detection The following conditions are checked as part of the periodic review described in section 2. They are performed as reconciliations against an authoritative record, run on the review cadence rather than continuously, and are documented as manual controls because that is what they currently are: - Repeated authentication failures against a single account, or spread across many accounts - Privileged access exercised outside an approved elevation, detected by joining infrastructure access records against the approved elevation window covering them - Operator access to a customer's data without a corresponding signed access grant - Loss of log ingestion from any source, treated as a loss of visibility rather than as an absence of events The second and third conditions are stated as reconciliations against an authoritative record rather than as behavioural anomalies. An alert that fires on a deviation from a learned baseline is only as good as the baseline; one that fires when an action has no matching authorization is either true or a bug in the authorization path, and both are worth knowing. Changes to logging configuration held in version control are covered by change review. Where a provider holds configuration outside version control, the change record available from that provider is what applies. Promoting these checks to continuous automated alerting is the intended end state, and each is written to be expressible as a rule. Until those rules exist, this policy does not claim them: the control is the review, at the frequency section 2 sets, and nothing here should be read as evidence that a condition is being detected in real time. This list is deliberately short. A condition is added when it can be expressed precisely and someone will act on it, not to broaden coverage on paper. ### 3.2 Risk-proportionate response Anomalies shall be responded to in a manner appropriate to the risk they represent: | Severity | Definition | Response | | --- | --- | --- | | High | Credible indication of unauthorized access to Confidential data, or compromise of a privileged account or production system | Triage immediately on detection. Escalate to the [Incident Response Management](/security/human-and-incident-management/incident-response-management) process. Contain first, investigate second. | | Medium | Suspicious activity that may indicate misuse or a control failure but with no confirmed exposure of Confidential data | Triage within one (1) business day. Investigate, determine root cause, and record the outcome. Escalate to incident response if exposure is confirmed. | | Low | Anomalies with a plausible benign explanation, such as a known operational change or a misconfigured client | Triage within five (5) business days. Record the disposition and, where the anomaly is expected to recur, tune the alert or the underlying control. | Every anomaly shall be closed with a documented disposition, even when the disposition is that no action was needed. Recurring low-severity anomalies that are dismissed repeatedly shall trigger a review of the alert rule so that alert fatigue does not mask real events. ### 3.3 Feedback into controls Findings from log reviews and anomaly investigations shall feed the [Risk management policy](/security/access-and-risk-management/risk-management-policy) risk register and, where relevant, result in changes to access controls, alerting thresholds, or logging coverage. ## 4. Roles and responsibilities **Security lead.** Owns this policy, approves logging and alerting configuration changes, ensures periodic reviews happen and are documented, and makes the severity call on escalated anomalies. **Engineering team.** Implements and maintains logging in applications and infrastructure, ensures new services log to the central pipeline before reaching production, performs first-line triage of alerts, and documents dispositions. **All personnel.** Report suspected security events they observe, whether or not an automated alert fired. ## 5. Evidence of compliance To demonstrate compliance, Tuist GmbH shall maintain: 1. Documentation of logging configuration per system, including which activity levels are captured 2. Records of periodic log reviews, including reviewer, date, scope, and findings 3. Alerting rule definitions and their change history 4. Records of anomaly investigations and their dispositions 5. Evidence of log retention settings and access controls on log storage ## Exceptions Systems that cannot meet the requirements of this policy shall have the limitation documented, a compensating control identified, and an exception approved by the IT Manager. Exceptions shall be reviewed at least annually. ## Violations and enforcement Any known violations of this policy should be reported to the IT Manager. Violations can result in immediate withdrawal or suspension of system and network privileges and disciplinary action in accordance with company procedures up to and including termination of employment. ## Review This policy shall be reviewed annually or when significant changes occur to Tuist GmbH's technology infrastructure. ## Appendix A: Logging coverage This appendix records what is captured at each activity level and where it is held. It is the documentation of logging configuration required by section 5, and it is maintained alongside the systems it describes. Every request handled by the Tuist server emits a structured completion record carrying the request identifier, the request kind, the acting account, the selected account and project where one is in scope, the method, the route, the response status, and the duration. Where a request runs under an operator access grant, the grant identifier and subject are attached to that same record. This single record is what provides actor, action, resource, outcome, and correlation identifier for most of what follows, which is why the table below points at it repeatedly rather than describing a separate log per event. ### Administrative activity | Event | Where it is captured | | --- | --- | | Authentication attempts and their outcome | Server request records, identified by route and response status, with the acting account attached | | Workforce authentication and multi-factor challenges | The identity provider's own audit log. The Tuist application does not authenticate workforce identity directly | | Account creation, modification, disablement, and deletion | Server request records; automated retirement of dormant accounts additionally emits a record naming every account actioned | | Role, permission, and organization membership changes | Server request records | | Privileged infrastructure elevation, with justification | Three independent records: the approval thread, the operations database, and the per-call access log of the cluster gateway | | Operator access to a customer account | The signed grant, joinable to every request made under it by the grant identifier | | Infrastructure, network, and deployment configuration changes | Version control history and the deployment pipeline's own run records | | Changes to logging configuration held in version control | Version control history | ### Application activity | Event | Where it is captured | | --- | --- | | Access to and modification of customer data and organization settings | Server request records, attributed to the selected account and project | | Creation, rotation, and revocation of tokens and other credentials | Server request records | | Administrative operations performed on customer accounts by Tuist personnel | Server request records carrying the operator grant identifier | | Export or bulk retrieval of data | Server request records | | Errors and exceptions indicating a security-relevant failure | Application error reporting, and the server's own error records | ### Transaction activity | Event | Where it is captured | | --- | --- | | Interface requests, with method, route, status, and originating account | Server request records | | Database schema migrations and administrative tasks | The output of the job that runs them, collected with all other workload output | | Object storage deletions, including those performed by scheduled retention and cleanup work | A dedicated record naming the operation, the account, the prefix or object count, and the outcome | | Billing and subscription state changes | The payment provider's event log, and the server request and webhook records that accompany each change | ### Where records are held Workload output is shipped off the originating host to the central telemetry platform, so no system holds the only copy of its own audit trail. Records held by third parties, including the identity provider and the payment provider, remain in those systems and are retrieved from them when a review or an investigation calls for it. ### Maintenance This appendix is reviewed whenever a new system is introduced, whenever an existing system changes what it records, and at the annual review of this policy. Where a governance process needs evidence that current coverage cannot produce, section 1.3 applies: the coverage is extended rather than the process weakened. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/secure-development-and-operations/penetration-testing-policy" LLMS_URL: "/security/secure-development-and-operations/penetration-testing-policy.md" title: "Penetration testing policy" titleTemplate: ":title | Secure development and operations | Security | Tuist Handbook" description: "Policy establishing the requirements for regular penetration testing of Tuist GmbH systems and applications to identify and remediate security vulnerabilities." --- # Penetration testing policy - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** June 19th, 2025 ## Purpose This policy establishes the requirements for regular penetration testing of Tuist GmbH's systems, applications, and infrastructure to identify security vulnerabilities that could potentially be exploited by malicious actors. Penetration testing provides an essential security assessment that goes beyond automated vulnerability scanning by simulating real-world attack scenarios to validate the effectiveness of security controls. ## Scope This policy applies to all systems, applications, and infrastructure owned, operated, or maintained by Tuist GmbH that are business-critical and/or process, store, or transmit Confidential data. It applies to all employees, contractors, and third parties involved in planning, conducting, or responding to penetration testing activities. This policy operates within Tuist's [shared responsibility model](/security/shared-responsibility-model). Infrastructure providers are responsible for testing the physical and hardware layers they operate, and the managed services they run themselves. Because Tuist GmbH operates its own Kubernetes clusters and its own primary database, the clusters, the node operating systems, and everything above them are Tuist GmbH's to test. ## Policy Statement Tuist GmbH shall conduct penetration testing **at least annually** on all Internet-exposed services and critical applications. Additional penetration tests shall be performed following significant changes to the application or when required by compliance requirements. ## Penetration Testing Requirements ### 1. Testing Frequency - **Annual Testing**: Comprehensive penetration testing of all critical systems at least once per year - **Event-Driven Testing**: Additional testing following: - Major infrastructure changes - Significant application updates or new feature releases - Security incidents or breaches - Discovery of critical vulnerabilities in similar systems - **Compliance-Driven Testing**: As required by customer contracts or regulatory requirements ### 2. Types of Penetration Testing The following types of penetration testing shall be conducted by Tuist: - **Web Application Penetration Testing**: Security assessment of Tuist-developed web applications and APIs - **API Security Testing**: Comprehensive testing of all Tuist API endpoints for authentication, authorization, and data validation vulnerabilities - **Business Logic Testing**: Assessment of application workflows and business processes for logical flaws - **Configuration Review**: Assessment of application-level configurations and security settings within Tuist's control - **Integration Testing**: Security assessment of integrations between Tuist applications and third-party services ### 3. Testing Scope In accordance with our [shared responsibility model](/security/shared-responsibility-model), Tuist's penetration testing scope focuses on: **Tuist's Responsibility (must be tested):** - All Tuist-developed web applications and APIs - Application-layer security controls and configurations - Authentication and authorization mechanisms implemented by Tuist - Custom integrations and API endpoints - Application-specific data handling and encryption - Business logic vulnerabilities - Kubernetes cluster configuration, in-cluster network policy, and workload isolation - Node operating systems across the Linux and macOS fleets - The in-cluster PostgreSQL and cache services - Isolation between customer build jobs running on the macOS fleet **Infrastructure Provider Responsibility (covered by provider testing):** - Physical data center security (Hetzner, Scaleway, OVHcloud) - Hardware, host network, and volumetric denial-of-service filtering (Hetzner, Scaleway, OVHcloud, Cloudflare) - The managed services providers operate themselves: object storage (Tigris), the analytics database (ClickHouse Cloud), the edge network (Cloudflare), telemetry storage (Grafana Cloud), and the secret vault (1Password) - Infrastructure-level access controls within those services Note that platform-level patching and cluster network security are not on this list. Under our model they belong to Tuist GmbH, not to a provider. ### 4. Testing Methodology Penetration testing shall follow industry-standard methodologies such as: - OWASP Testing Guide for web applications - PTES (Penetration Testing Execution Standard) - NIST SP 800-115 Technical Guide to Information Security Testing - Cloud-specific frameworks for cloud infrastructure testing ### 5. Authorized Testing Providers Penetration testing must be conducted by: - **External Testing**: Qualified third-party security firms with demonstrated expertise and appropriate certifications (e.g., OSCP, GPEN, CEH) - **Internal Testing**: Authorized security personnel with appropriate training and certifications (if applicable) - All testers must sign appropriate confidentiality agreements before testing begins ### 6. Pre-Testing Requirements Before penetration testing begins: - Written authorization must be obtained from the CTO - Testing scope and timeline must be documented - Rules of engagement must be established, including: - Testing windows to minimize business impact - Excluded systems or activities - Communication protocols - Team members must be notified of testing activities ### 7. Testing Execution During penetration testing: - All testing activities must be logged and documented - Testing must be conducted according to the agreed rules of engagement - Any critical vulnerabilities discovered must be immediately reported - Testing that could cause service disruption must be carefully managed - Communication channels must remain open between testers and Tuist personnel ### 8. Post-Testing Requirements After penetration testing is complete: - A comprehensive report must be provided within 2 weeks, including: - Executive summary - Detailed findings with severity ratings - Evidence of successful exploitation - Remediation recommendations - Risk ratings and business impact analysis - A remediation plan must be developed based on findings - Retesting must be conducted to verify remediation of critical and high findings ### 9. Remediation Requirements Vulnerabilities discovered during penetration testing shall be remediated according to: - Critical: Within 7 days - High: Within 14 days - Medium: Within 30 days - Low: Within 90 days Any deviation from these timelines requires documented risk acceptance by the CTO. ### 10. Documentation and Record Keeping The following documentation must be maintained: - Penetration testing scope and authorization documents - Testing reports and findings - Remediation plans and evidence - Retest results - Risk acceptances for any exceptions - Certificates of testing completion - Infrastructure provider security certifications and attestations (SOC 2, ISO 27001, etc.) All penetration testing documentation shall be retained for a minimum of 3 years. ### 11. Infrastructure Provider Assurance To ensure comprehensive security coverage: - Maintain copies of infrastructure provider security certifications (SOC 2, ISO 27001) - Monitor provider security bulletins - Review the shared responsibility model annually ## Vendor Management When engaging third-party penetration testing providers: - Vendors must provide evidence of appropriate insurance coverage - Vendors must demonstrate relevant certifications and experience - Non-disclosure agreements must be executed before sharing any information - Vendor personnel must be vetted and approved - Clear communication protocols must be established ## Evidence Collection and Reporting To satisfy audit and compliance requirements: 1. Maintain penetration testing reports and completion certificates 2. Track remediation progress 3. Document evidence of critical vulnerability fixes ## Roles and Responsibilities ### Chief Technology Officer (CTO) - Approves penetration testing schedule and budget - Authorizes testing activities - Reviews testing reports and approves remediation priorities - Accepts risk for any deviations from remediation timelines ### Engineering Team - Coordinates with testing providers - Implements remediation for identified vulnerabilities - Documents remediation actions - Monitors systems during testing ## Exceptions Any exceptions to this policy must be documented and approved by the CTO. Exceptions shall include: - Reason for the exception - Duration of the exception - Any compensating controls - Risk acceptance ## Compliance Monitoring Compliance with this policy shall be monitored through annual review of: - Penetration testing completion - Remediation status - Testing documentation ## Policy Review This policy shall be reviewed annually or when significant changes occur to Tuist's technology infrastructure or threat landscape. ## Version History The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/secure-development-and-operations/secure-development-policy" LLMS_URL: "/security/secure-development-and-operations/secure-development-policy.md" title: "Secure development policy" titleTemplate: ":title | Secure development and operations | Security | Tuist Handbook" description: null --- # Secure development policy - **Policy owner:** Pedro Piñera Buendía - **Policy owner:** Effective Date: Oct 16, 2024 ## Purpose To ensure that information security is designed and implemented within the development lifecycle for applications and information systems. ## Scope All Tuist GmbH applications and information systems that are business critical and/or process, store, or transmit Confidential data. This policy applies to all internal and external engineers and developers of Tuist GmbH software and infrastructure. ## General requirements This policy describes the rules for the acquisition and development of software and systems that shall be applied to developments within the Tuist GmbH organization. ## System change control procedures Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures. Change control procedures and requirements are described in the Tuist GmbH Operations Security Policy. Significant code changes must be reviewed and approved by Pedro Piñera Buendía before being merged into any production branch in accordance with the process found here: https://handbook.tuist.io/engineering/standard-practices Change control procedures shall ensure that development, testing and deployment of changes shall not be performed by a single individual without approval and oversight. ## Software version control All Tuist GmbH software is version controlled and synced between contributors (developers). Access to the central repository is restricted based on an employee's role. All code is written, tested, and saved in a local repository before being synced to the origin repository. ## Technical review of applications after operating platform changes When operating platforms are changed, business critical applications shall be reviewed and tested to ensure that there is no adverse impact on organizational operations or security. ## Restrictions on changes to software packages Modifications to third-party business application packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled. ## Secure system engineering principles Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts. At a minimum, the following secure-by-design and privacy-by-design principles shall be applied: Secure-by-design principles: 1. Minimize attack surface area 2. Establish secure defaults 3. The principle of Least privilege 4. The principle of defense in depth 5. Fail securely 6. Don't trust services 7. Separation of duties 8. Avoid security by obscurity 9. Keep security simple 10. Fix security issues correctly Privacy-by-design principles: 1. Proactive not Reactive; Preventative not Remedial 2. Privacy as the Default Setting 3. Privacy Embedded into Design 4. Full Functionality - Positive-Sum, not Zero-Sum 5. End-to-End Security - Full Lifecycle Protection 6. Visibility and Transparency - Keep it Open 7. Respect for User Privacy - Keep it User-Centric Engineering documentation and technical references can be found in the process here: https://handbook.tuist.io Software developers are expected to adhere to Tuist GmbH's coding standards throughout the development cycle, including standards for quality, commenting, and security. ## Secure development environment Tuist GmbH shall establish and appropriately protect environments for system development and integration efforts that cover the entire system development lifecycle. The following environments shall be logically or physically segregated: - Production - Test / Staging / Canary - Development ## System security testing Testing of security functionality shall be performed at defined periods during the development life cycle. No code shall be deployed to Tuist GmbH production systems without documented, successful test results and evidence of security remediation activities. Comprehensive penetration testing shall be performed at least annually on applications and cloud resources according to the requirements outlined in the Penetration Testing Policy. As per our [Shared Responsibility Model](/security/shared-responsibility-model), providers test the physical and hardware layers they operate. Tuist GmbH runs its own Kubernetes clusters, so testing of the cluster network and everything above it falls to Tuist GmbH rather than to a provider. Application-level network traffic shall be monitored, controlled, managed, and periodically evaluated to identify vulnerabilities, anomalies, and capacity issues in accordance with the [Network Traffic Management Policy](/security/business-continuity-and-data-protection/network-traffic-management-policy). Systems and applications shall log administrative, application, and transaction level user activity, and those logs shall be reviewed and acted upon in accordance with the [Logging and Monitoring Policy](/security/secure-development-and-operations/logging-and-monitoring-policy). ## Application vulnerability management Application code and dependencies should be scanned continuously using GitHub Dependabot, Snyk, Sobelow, and Trivy according to the requirements outlined in the [Vulnerability Scanning Policy](../secure-development-and-operations/vulnerability-scanning-policy.md). All Internet-exposed services and remote client applications shall undergo weekly vulnerability scanning. Sobelow shall be used for detecting vulnerabilities in Elixir application code with each commit, and Trivy shall be used for scanning repositories and Docker images before merging into main, both causing CI pipeline failures if security issues are detected. Patches to address application vulnerabilities shall be deployed according to the severity-based timelines defined in the Vulnerability Scanning Policy. ## System acceptance testing Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new versions. Prior to deploying code, a Release Checklist MUST be completed which includes a checklist of all Test Plans which show the completion of all associated tests and remediation of identified issues. ## Protection of test data Test data shall be selected carefully, protected and controlled. Confidential customer data shall be protected in accordance with all contracts and commitments. Customer data shall not be used for testing purposes without the explicit permission of the data owner and the CTO. ## Acquisition of third-party systems and software The acquisition of third-party systems and software shall be done in accordance with the requirements of the Tuist GmbH Third-Party Management Policy. ## Developer training Software developers shall be provided with secure development training appropriate to their role at least annually. Training content shall be determined by management but shall address the prevention of common web application attacks and vulnerabilities. The following threats and vulnerabilities should be addressed as appropriate: - Prevention of authorization bypass attacks - Prevention of the use of insecure session IDs - Prevention of Injection attacks - Prevention of cross-site scripting attacks - Prevention of cross-site request forgery attacks - Prevention of the use of vulnerable libraries ## Exceptions Requests for an exception to this Policy must be submitted to the IT Manager for approval. ## Violations & enforcement Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Version history The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/secure-development-and-operations/vulnerability-scanning-policy" LLMS_URL: "/security/secure-development-and-operations/vulnerability-scanning-policy.md" title: "Vulnerability scanning policy" titleTemplate: ":title | Secure development and operations | Security | Tuist Handbook" description: "Policy detailing the requirements for regular vulnerability scanning of Tuist GmbH systems, applications, and dependencies." --- # Vulnerability scanning policy - **Policy owner:** Pedro Piñera Buendía - **Effective Date:** April 25, 2023 ## Purpose This policy establishes the requirements for regular vulnerability scanning of Tuist GmbH's systems, applications, and dependencies to identify security vulnerabilities that could potentially be exploited by malicious actors. Regular vulnerability scanning is a critical component of Tuist's security program that helps ensure the confidentiality, integrity, and availability of our systems and data. ## Scope This policy applies to all systems, applications, and code repositories owned, operated, or maintained by Tuist GmbH that are business-critical and/or process, store, or transmit Confidential data. It applies to all employees, contractors, and third parties who manage or develop systems for Tuist GmbH. ## Policy Statement Tuist GmbH shall perform automated vulnerability scanning **at least weekly** on all Internet-exposed services and remote client applications. Dependency vulnerability scanning shall be performed continuously through automated tools integrated into our development pipeline. ## Vulnerability Scanning Requirements ### 1. Frequency and Timing - **Internet-Exposed Services**: Weekly automated vulnerability scanning - **Remote Client Applications**: Weekly automated vulnerability scanning - **Code Dependencies**: Continuous monitoring via GitHub Dependabot and Snyk - **Development Repositories**: Scan on every pull request and at least daily for the main branch ### 2. Scanning Tools Tuist GmbH uses the following tools for vulnerability scanning: - **GitHub Dependabot**: Configured to scan all GitHub repositories for vulnerable dependencies - **Snyk**: Used for dependency vulnerability scanning, application security testing, and container scanning - **Sobelow**: Used for detecting security vulnerabilities in Elixir code - **Trivy**: Used for scanning repositories and Docker images for vulnerabilities before merging into main - **[Additional tools as applicable]**: For network vulnerability scanning of Internet-exposed services ### 3. Types of Scanning Vulnerability scanning shall include, at minimum: - **Dependency Scanning**: Identification of vulnerable third-party libraries and components using GitHub Dependabot, Snyk, and Trivy - **Code Scanning**: Detection of security issues in Elixir application code using Sobelow, with additional scanning by Snyk - **Container Scanning**: Examination of container images for vulnerabilities using Snyk and Trivy - **Network Scanning**: Assessment of Internet-exposed endpoints for configuration issues and known vulnerabilities - **Repository Scanning**: Comprehensive scanning of repositories using Trivy before merging into main branch ### 4. Scan Coverage Vulnerability scans must cover: - All production applications and services - All staging environments accessible from the Internet - All third-party libraries and dependencies - All container images used in production environments - All remote client applications ### 5. Scan Configuration At minimum, vulnerability scanning tools must be configured to: - Run automatically at the defined intervals - Include the latest vulnerability definitions and signatures - Produce detailed reports identifying the severity of findings - Generate alerts for critical and high severity findings - Minimize performance impact on production systems ### 6. Remediation Requirements Vulnerabilities discovered during scanning shall be remediated according to the following timelines: - Critical: Within 7 days - High: Within 14 days - Medium: Within 30 days - Low: Within 90 days Any deviation from these timelines requires a formal risk acceptance by the IT Manager and CTO. ### 7. False Positive Management All potential false positives shall be: - Documented with justification for the false positive determination - Reviewed by security personnel - Periodically reassessed to ensure the status remains accurate ### 8. Documentation and Record Keeping The following documentation must be maintained for vulnerability scanning: - Scan configurations and schedules - Scan results and reports - Remediation plans and status - Evidence of remediation for critical and high findings - Risk acceptances for any exceptions All vulnerability scanning documentation shall be retained for a minimum of 2 years. ## Tool-Specific Implementation ### GitHub Dependabot Configuration 1. **Enabling**: Dependabot is enabled on all GitHub repositories via the `.github/dependabot.yml` configuration file. 2. **Configuration**: - Security updates are configured to run daily - Dependency version updates are configured to run weekly - Pull requests are automatically created for security vulnerabilities 3. **Review Process**: - All Dependabot pull requests are reviewed within 48 hours - Critical vulnerabilities are prioritized for immediate review 4. **Documentation**: Screenshots of Dependabot configurations and alert dashboards are captured quarterly for compliance evidence ### Snyk Configuration 1. **Integration**: Snyk is integrated with our GitHub repositories, CI/CD pipelines, and container registries. 2. **Scanning Frequency**: - Code repositories are scanned continuously, with each commit/PR - Container images are scanned before deployment - Projects are monitored continuously for new vulnerabilities 3. **Alert Configuration**: - Critical and high severity alerts trigger notifications to the security team - Weekly summary reports are generated and reviewed 4. **Documentation**: Screenshots of Snyk dashboard showing scan configurations, coverage, and results are captured monthly for compliance evidence ### Sobelow Configuration 1. **Integration**: Sobelow is integrated into our CI/CD pipelines for Elixir projects. 2. **Scanning Frequency**: - Code is scanned for vulnerabilities with each commit - CI/CD pipeline is configured to fail if security issues are detected - Configured to detect common vulnerabilities in Phoenix applications 3. **Alert Configuration**: - Security findings are reported directly in the CI/CD pipeline - Developers are immediately notified of security issues - Merge is blocked until security issues are resolved 4. **Documentation**: Screenshots of CI/CD configurations and Sobelow output are captured monthly for compliance evidence ### Trivy Configuration 1. **Integration**: Trivy is integrated into our CI/CD pipelines for repository and Docker image scanning. 2. **Scanning Frequency**: - Repository contents are scanned for vulnerabilities before merging into main - Docker images are scanned for vulnerabilities during the build process - Configured to detect vulnerabilities in multiple layers of the application stack 3. **Alert Configuration**: - Security findings are reported directly in the CI/CD pipeline - Pull requests are blocked from being merged if high or critical vulnerabilities are detected - Detailed reports are generated for remediation 4. **Documentation**: Screenshots of Trivy scan configurations and results are captured monthly for compliance evidence ## Evidence Collection and Reporting To satisfy audit and compliance requirements, Tuist shall: 1. Capture screenshots of vulnerability scanning tool configurations showing: - Scan schedules and frequency - Coverage of all in-scope systems - Alert configurations 2. Generate and maintain vulnerability scanning reports: - Weekly summary of new vulnerabilities discovered - Monthly trending reports showing vulnerability remediation progress - Quarterly compliance reports showing adherence to remediation timelines 3. Document remediation activities: - Tickets/issues created for vulnerability remediation - Evidence of patches or fixes applied - Verification scans confirming remediation ## Roles and Responsibilities ### IT Manager/Security Lead - Ensures vulnerability scans are scheduled and performed at required intervals - Reviews scanning reports and prioritizes remediation efforts - Approves exceptions and risk acceptances when necessary - Ensures compliance with this policy ### Development Teams - Implement fixes for identified vulnerabilities within the required timeframes - Review and address Dependabot and Snyk alerts - Participate in vulnerability remediation planning - Document remediation actions ### Operations Teams - Assist in implementing fixes for infrastructure or configuration vulnerabilities - Schedule scanning to minimize impact on production systems - Verify remediation effectiveness through follow-up scans ## Exceptions Any exceptions to this policy must be documented and approved by the IT Manager and the Chief Technology Officer. Exceptions shall be documented with: - The specific reason for the exception - The scope and duration of the exception - Any compensating controls implemented - Risk assessment of the exception - Approval signatures from authorized personnel ## Compliance Monitoring and Enforcement Compliance with this policy shall be monitored through: - Weekly review of scanning reports from Dependabot, Snyk, Sobelow, and Trivy - Monthly audit of remediation timelines - Quarterly review of scanning coverage and configuration for all security tools Any known violations of this policy should be reported to the IT Manager. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment. ## Policy Review This policy shall be reviewed annually or when significant changes occur to Tuist's technology infrastructure. ## Version History The version history of this document can be found in Tuist's [handbook](https://github.com/tuist/handbook) repository. --- URL: "/security/shared-responsibility-model" LLMS_URL: "/security/shared-responsibility-model.md" title: "Shared responsibility model" titleTemplate: ":title | Security | Tuist Handbook" description: "Where the security boundary falls between Tuist GmbH and each of its infrastructure providers." --- # Shared responsibility model Tuist runs its own Kubernetes clusters on rented hardware. We do not use a managed application platform, so the boundary between us and our providers sits lower than a platform-as-a-service model would put it. Providers are accountable for physical infrastructure and for the managed services they operate themselves. Everything from the operating system upward, including Kubernetes and our primary database, is ours. This distinction matters more than it might sound. Under a platform model, the cluster, the runtime, and often the database sit on the provider's side of the line. Under ours they do not. Any statement that a provider handles our cluster or our primary database is wrong. ## Where the line falls | Layer | Responsible | | --- | --- | | Data centre, power, cooling, physical hardware | Provider | | Host network, hardware-level volumetric attack filtering | Provider | | Node operating system and its patching | Tuist | | Kubernetes control plane, workers, networking, upgrades | Tuist | | Platform components: ingress, certificate issuance, secret sync, autoscaling | Tuist | | PostgreSQL and Valkey, both in-cluster | Tuist | | Managed analytics database, object storage, edge network | Provider operates, Tuist configures and controls access | | Telemetry storage | Provider stores, Tuist decides what is sent and who may read it | | Application code, dependencies, data model | Tuist | | Identity, authorization, and the access lifecycle | Tuist, on top of the identity provider | ## Hetzner: cluster compute Cloud instances and bare metal that host our Kubernetes clusters. Machine lifecycle is driven by Cluster API with the Hetzner provider; load balancers and block storage are Hetzner services. **Hetzner is responsible for** physical data centre security, power and cooling, the hardware and hypervisor, the host network, filtering of network-level volumetric attacks, and the availability of the cloud API, load balancer, and block storage services. **Tuist is responsible for** everything above the machine: the node operating system and its patch level, the Kubernetes control plane and worker configuration, cluster upgrades, in-cluster network policy, workload and namespace isolation, firewall rules, and encryption of the data we place on attached volumes. ## Scaleway: macOS fleet and bare metal Apple Silicon Mac minis and bare metal, ordered and released through Scaleway's API by our own Cluster API provider. The Mac minis run virtual machines that execute customer build jobs. **Scaleway is responsible for** the data centre, the hardware, the host network, and the availability of the machines and their API. **Tuist is responsible for** the contents and patch level of the macOS images we bake, the agent that registers each host as a cluster node, the virtual machine boundary that separates one customer's build from another's, credential handling on the host, and the separation of per-account caches. ## OVHcloud: cache regions Bare metal in Vint Hill, Virginia and Hillsboro, Oregon hosting regional cache nodes. The split matches Scaleway. Hardware and host network are OVHcloud's. The operating system, cluster membership, and the cache workload itself are ours. ## Tigris: object storage Customer artifacts, build outputs, previews, and database backups. **Tigris is responsible for** durability and availability of the store, encryption in transit and at rest, isolation between tenants, and the security of the storage infrastructure. **Tuist is responsible for** bucket layout and lifecycle rules, access keys and their rotation, what data is written and how long it is kept, the authorization check that runs before any object is served, and encrypting sensitive values before they are stored. For additional detail, see Tigris's [privacy policy](https://www.tigrisdata.com/docs/legal/privacy-policy/#6-security). ## ClickHouse Cloud: analytics database The managed ClickHouse service holding build and test analytics. **ClickHouse Cloud is responsible for** operating, patching, backing up, and keeping the database available, encryption in transit and at rest, and the security of the underlying infrastructure. **Tuist is responsible for** the schema, what data is written and for how long, network exposure, query memory bounds, and the restricted role the application reads through. That role is re-derived and its password rotated on every server rollout, and it holds no privileges over external sources, files, dictionaries, users, or access management. ## Cloudflare: domain name service and edge Authoritative name service, certificate validation, and the workers that route the package registry path and serve the public status page. **Cloudflare is responsible for** the availability and security of the edge network, absorbing volumetric denial-of-service traffic, and the worker runtime. **Tuist is responsible for** name records, edge rules and rate limits, worker code, certificate issuance policy, and keeping origins from being reachable around the edge. ## Grafana Cloud: logs, metrics, and traces Telemetry leaves the cluster through an agent we run inside it. **Grafana is responsible for** the durability, availability, and access control of the telemetry store, and the security of its platform. **Tuist is responsible for** what is logged and what is deliberately kept out of logs, redaction before anything is shipped, retention settings, dashboards and alert rules, and who is allowed to read logs. The requirements are in the [Logging and monitoring policy](/security/secure-development-and-operations/logging-and-monitoring-policy). ## 1Password: secret storage Every runtime secret originates in 1Password and is synchronized into the clusters by the External Secrets Operator. **1Password is responsible for** the cryptographic design of the vault, its availability, and platform security. **Tuist is responsible for** vault structure and membership, which secrets exist and when they rotate, the synchronization configuration, and ensuring a synchronized secret is not readable by the wrong workload or through human read-only cluster access. ## Google Workspace: identity Workforce identity, and the authentication source for cluster access. **Google is responsible for** the security and availability of the authentication platform. **Tuist is responsible for** the account lifecycle described in the [Access control policy](/security/access-and-risk-management/access-control-policy), group membership, enforcing multi-factor authentication, and every authorization decision made once an identity has been established. ## Tailscale: private network Internal service access and operator paths that are deliberately not exposed publicly. **Tailscale is responsible for** the security and availability of its coordination service. **Tuist is responsible for** the access control list, which is a static and code-reviewed document rather than something mutated at runtime, device and tag membership, and the decision about what is reachable on the private network rather than the public internet. ## Other services GitHub for source control, continuous integration, and container images. Stripe for payments. Mailgun for transactional email. Sentry for error reporting. Each provider secures its own platform; Tuist controls its configuration, who can access it, and what data is sent to it. All are assessed under the [Third-party risk management policy](/security/access-and-risk-management/third-party-risk-management-policy). ## What no provider covers Worth stating plainly, because it is the part a standard shared responsibility model would place elsewhere: - The Kubernetes clusters, including the control plane, and their upgrade cadence - The operating system on every node, across Linux and macOS - PostgreSQL and Valkey, which run inside our clusters rather than as managed services - The application, its dependencies, and its data model - Identity, authorization, and the access lifecycle If a control in one of these areas is not performed by us, it is not performed at all. ## Review This document is reviewed annually and whenever a provider is added or removed. If you have questions about this model, please reach out to the security team at [contact@tuist.dev](mailto:contact@tuist.dev). --- URL: "/support/process" LLMS_URL: "/support/process.md" title: "Support process" titleTemplate: ":title | Support | Tuist Handbook" description: "Learn how we provide support to developers and organizations using Tuist." --- # Support process Developers and organizations might run into issues or have questions while using Tuist. When that happens, we need to ensure their input is processed promptly and the proper context is captured to understand the problem or need and prioritize it accordingly. This page outlines the processes that we have in place for providing the best support. ## Default to GitHub By default, we use GitHub to provide support through [GitHub Issues](https://github.com/features/issues), and we expect developers and organizations to create issues in the repository associated with the project they are having issues with. Most will do so in the [tuist/tuist](https://github.com/tuist/tuist) repository to provide support, which takes priority over issues in other open-source repositories that we maintain. When providing support: - Ensure the issue contains all the necessary information to understand the problem or need and includes a [reproducible project](https://docs.tuist.io/contributors/issue-reporting.html#reproducible-project) and steps. If it doesn't, assign the status `Needs reproduction/response` in the Tuist GitHub project. - If the person is blocked, provide a workaround if possible. - Assign the priority based on the following criteria: - **P0**: Critical issue that prevents them from using a paid feature or the tool. - **P1**: Critical issue that prevents them from using the tool (no workaround exists). - **P2**: Important issue that doesn't prevent them from using the tool. - **P3**: Nice-to-have feature or improvement. > [!IMPORTANT] P0 ISSUES > P0 Issues should become an immediate priority and be worked on as soon as possible. > [!NOTE] SLACK > We should expect that people might use the community Slack to seek support. We should monitor the Slack channel and redirect them to GitHub Issues if they haven't already created an issue. Slack is not the best support channel to use at scale. ## Priority support **Tuist Enterprise organizations** can use the cross-Slack channel to get priority support. Tickets reported through this channel get the highest priority. **Tuist Pro organizations** can use the `support@tuist.io` email to get priority support and a cross-slack channel. We process those emails through [Intercom](https://intercom.com), so if you are expected to provide support, you'll have access to the Intercom inbox. Assign new tickets to you to signal that you are working on them.