Company context: tell the assistant who you are, once

The first clause a serious information security standard asks you to satisfy is not a control. ISO/IEC 27001:2022 (published October 2022) devotes Clause 4 to the "context of the organization," and it opens, in 4.1, with "understanding the organization and its context." Before scope, before the Statement of Applicability, before a single policy, the standard wants to know who you are: what you do, who you serve, what could go wrong for a company shaped like yours.

An AI assistant that skips that clause writes generic compliance. Ask it for an access control policy and, if it knows nothing about you, it hands back a template that could belong to a 5,000-person bank or a three-person startup. The words are fine. The document is for a company that does not exist.

Until now, you improvised. You repeated who you are at the top of each conversation, or wedged your org facts into freeform custom instructions, or let the assistant pick them up one at a time as saved memories. Each can hold a fact. None is a home for your organization's identity. Facts scattered across a hundred threads are not context, they are repetition.

What we shipped

Company context is a structured profile for your organization, in one place, in the new Customize area in the sidebar. You fill in a short form of the facts that change how compliance advice should read:

• Company name and sector
• Scale (size, stage, or headcount band)
• HQ country and hosting region (where your data lives)
• Privacy role: controller, processor, or both
• Data types you handle (personal or regulated data classes)
• Tech stack (core systems, cloud, identity provider)
• Notes: anything else the assistant must know, up to 2,000 characters

You set it once. From then on, your personal Chat and Beyond draft with your company in mind. Ask for a risk assessment and it reasons about your data types and hosting region, not a stock example. Ask for a policy and it fits your scale instead of a generic org chart. The privacy role field alone changes a lot: GDPR Article 4 (the Regulation has applied since 25 May 2018) defines what a controller and a processor are, and the GDPR assigns each of them different responsibilities, so telling the assistant which one you are is the difference between advice that applies to you and advice that does not.

Three different things, so you stop confusing them

People conflate three settings that do different jobs. Company context exists so you do not have to pick the wrong one.

• Company context is who your organization is. Structured, durable facts. Set it and forget it.
• Custom instructions are how you want the assistant to behave. Tone, format, house style. A preference, not a fact.
• Saved memories are incremental facts the assistant picks up as you go. Useful, but accumulated one at a time rather than declared upfront.

Before company context, your organization's identity had nowhere clean to live, so it leaked into the other two: a paragraph about your sector wedged into custom instructions, a headcount half-remembered from a memory saved months ago. Now there is a form for the org, and the other two are free to do their own jobs.

Your connected agents can read and write it too

Company context is not only a web form. If you use ISMS Copilot from a coding tool over MCP (Claude Code, Cursor, or another compatible MCP client, the same connection described in Connect ISMS Copilot to Claude Code), your agent can read and update your company context directly, with your permission.

This matters because the place you keep your real org facts is often not a browser tab. It is your repo, your infrastructure config, your codebase. Company context does not read those sources itself, but an agent that already works in them can. A connected agent can take your hosting region or tech stack from what it already sees in your environment and write it into your context, using scoped, least-privilege permissions you grant to the token: read access and write access are separate, so you can let an agent read your context without letting it change it. Set your context in the editor you already work in, and Chat and Beyond on the web read the same profile.

Honest scope

Company context is account-level: one profile for you, applied whether or not you have a workspace selected. It describes your organization.

Two places deliberately do not receive it. A temporary chat does not get your company context profile. And a shared team thread does not carry it either, because the profile is yours: one member's company facts should not silently become the context for everyone in a shared conversation. Company context is applied to your own personal Chat and Beyond, not to those two.

If you are a consultant running one workspace per client, this is not where per-client facts go. A client's specifics still belong in that workspace's instructions, pinned documents, and memories, the per-client overlay that keeps each engagement separate. Company context is the layer underneath: it is you, the practitioner or the in-house team, not the client of the week.

This is version one. It does not yet pull facts from Google Drive, Notion, or your other connected sources; you enter them. That automatic path is on the roadmap, not shipped, and we would rather say so than imply it works today.

Who it is for

• In-house teams doing repeated compliance work, tired of re-establishing who they are at the top of every thread.
• Practitioners who want drafts that fit, where the sector, scale, and data types are baked in instead of edited back in after every generation.
• Developers using the account API or a connected agent, who would rather set org facts from their own environment than open a settings page.

If you only ever ask one-off questions, you can skip it. Company context earns its keep the moment you notice you are explaining your company for the tenth time.

Try it

Open Customize in the sidebar and open Company context. Fill in what you know, even a few fields help, and save. Then start a fresh chat and ask for something you would normally have to preface with a paragraph about your org, like "draft an access control policy for us." The draft should already fit your company. If it does not, the field it missed is the field to fill in next.

Understanding the organization and its context is Clause 4.1 for a reason. An assistant should not make you skip it.