Signing up, and what actually exists afterwards

You have just signed up. This article says what now exists, what you have to decide, and — the part most onboarding guides leave out — what you should deliberately not do for a week or two. It is written for whoever owns the business rather than whoever runs the network, because the decisions in it are commercial as much as technical.

The short version: signing up creates a container and an account. It does not, on its own, tell you anything about your business. The step that does that is connecting Microsoft 365, it costs one consent and about ten minutes, and there is very little point doing anything else first.

What signing up creates

Four things come into existence in a single transaction. If any one of them fails, none of them is created, so you will never end up with an organisation that has no administrator or an administrator with no organisation.

An organisation, bound to a home region

The container for everything Qorionix will ever hold about your business — the Microsoft 365 connection, the posture findings, the alerts, the audit trail, the billing relationship. It is stamped with a home region at the moment it is created. Every workspace lands in the same place: Qorionix's one production cell, hosted in the EU (Ireland). A request arriving with a token from a different region would be refused rather than quietly served, but there is no second region to land in today.

A bootstrap administrator — you

Whoever completes signup becomes the first member of the organisation and holds the admin role, which carries every permission in the catalogue automatically, including permissions added by future releases. That last property matters: a new module cannot lock the person who owns the organisation out of it.

Three built-in roles

admin, member and viewer are created with the organisation, along with the grant policy that decides what each one may do. You do not have to design a permission model before you can use the product. See Who can see and do what.

A licence record

A row carrying your tier, the modules enabled on it, a seat ceiling, a retention period in days, whether the AI features are on, and the dates the licence is valid between. Everything the platform will and will not let you reach is decided from that one row.

You then have to sign in. Signup does not leave you authenticated — it returns your user and organisation identifiers and tells the client that a login is required. That is deliberate: the credential you just set should be exercised once before you rely on it.

The name, and the address derived from it

Your organisation name produces a URL label, and that label becomes a hostname your staff will see. Because it is a hostname rather than a cosmetic string, the platform will not invent one it cannot make valid. A name that reduces to fewer than three characters, a name written entirely in a script that does not transliterate, or a name that collapses onto one of the platform's own reserved words all produce a refusal rather than a mangled guess:

invalid organization slug: organization_slug is required because
  "Support" does not yield a usable subdomain label

Supply a label of your own when you see this. The wizard itself, the URL slug and the invitation flow are covered step by step in Create your organisation and invite your team, which is the article to open if you are partway through signup right now.

What the licence record actually decides

Four fields on that row govern your day-to-day experience, and it is worth knowing which of them the server enforces today and which are, for now, a statement of intent.

One consequence worth acting on: if your subscription page shows a tier or a module set that does not match what you believe you bought, tell us before you build a rollout plan on it. It is a two-minute correction now and a confusing week later.

The two decisions that are actually yours

Almost everything else can be changed later without cost. These two shape the next month, so spend ten minutes on them.

1. 1

   Which modules you intend to switch on, and in what order

   There are four — identity, privileged access, logs and detection, endpoints — plus the Microsoft 365 posture assessment, which is not a module and needs nothing except one consent. They demand very different things of you: a consent, an agent rollout across your machines, or an inventory of privileged credentials you probably do not have written down. Choosing which modules to turn on gives a recommended order and the reason for each position in it.

2. 2

   Who else gets an account, and with which role

   The honest answer is fewer people than you expect. Qorionix watches identities in Microsoft 365 without those people ever signing in here, so most of your staff need no Qorionix account at all. Accounts are for the people who approve changes, respond to alerts or answer auditors. Inviting your team sets out who genuinely needs one.

The one thing to do first

Connect Microsoft 365 and read the report. It is the fastest value in the product by a wide margin, and nothing else you could do this week competes with it.

The assessment runs 82 deterministic checks across privilege, authentication, access policy, hygiene, exposure, devices, applications, logging and licensing, and it produces a document naming your actual administrators, your actual applications, your actual devices and your actual risky sign-ins. Discovery targets thirty minutes unattended, and the platform measures the elapsed time against its own one-hour claim rather than assuming it. Nothing in the procedure changes a setting in your tenant, adds a prompt for your staff, or installs anything on a machine.

Most organisations we onboard find at least one thing in that first report they did not know: a former employee still holding a licence, an application nobody remembers approving, a mailbox quietly forwarding to an outside address. That is the artefact that makes the rest of the platform worth configuring, which is why it comes before the configuring.

What can wait, and what you should not do yet

Four tempting activities that will consume your first fortnight and return very little.

• Do not deploy the endpoint sensor to every machine on day one. It is the most visible thing on the feature list and the least urgent thing on your list. Identity is where the overwhelming majority of incidents at your size begin, it is cheaper to fix, and it disrupts nobody. The sensor can follow in week three.
• Do not invite your whole staff list. An account nobody uses is an account nobody notices being used. Invite the two or three people who will actually do something in the console, and leave the rest as identities the platform watches rather than users it authenticates.
• Do not write a security policy yet. A policy describing controls you have not implemented is a liability rather than an asset. Fix what the first report tells you to fix, then write the policy that describes what you actually did.
• Do not judge the detection queue in week one. Behavioural detections need five to fourteen days of your real traffic before their output means anything. During that period some will be quiet and some will be noisy, and neither tells you anything. That is a property of the data, not of the software, and nobody can compress it.

What to do next

1. Connect Microsoft 365 — one consent, read-only, about fifteen minutes of setup and half an hour of waiting.
2. Choose which modules to turn on — what each one needs from you, and the order we would do them in.
3. Work through the first-week checklist — eight items ordered by risk removed per unit of disruption caused.
4. Read what the platform does and does not do — twenty minutes that will calibrate every expectation you have for the next month.