Question 1

What is regulation10.ae?

Accepted Answer

regulation10.ae is the compliance plane for firms governed by DIFC Data Protection Regulation 10. Register each AI system, run the checks, and keep audit-ready proof, with tenant data resident in UAE North.

Question 2

How much does regulation10.ae cost?

Accepted Answer

regulation10.ae has four annual tiers: Starter (1 AI system, 1 seat included.), Professional (5 AI systems, 5 seats included, more at 299 US dollars per seat per year.), Enterprise (25 AI systems, 5 seats included, more at 299 US dollars per seat per year.), Sovereign (unlimited AI systems, 5 seats included, more at 299 US dollars per seat per year.). Public pricing is being finalised ahead of launch; use the plan configurator at /configure to see which tier fits, or sign up to be notified.

Question 3

Where is my data stored?

Accepted Answer

Tenant data for regulation10.ae is resident in UAE North.

Question 4

Which compliance frameworks does regulation10.ae cover?

Accepted Answer

regulation10.ae covers DIFC Reg 10, EU AI Act, ISO 42001, NIST AI RMF.

Question 5

How do I register an AI system?

Accepted Answer

To register an AI system, open the AI Systems page and click Register a system (or Add system). The form asks for a name, an owner, a purpose, and a lifecycle stage, and then asks you to classify the system's risk. When you save, the system joins your inventory and becomes the subject you run compliance work against.

Each field earns its place. The name identifies the system in reports and exports, so pick the name your organisation actually uses for it internally. The owner is the person accountable for the system's compliance record; they are who a reviewer will ask when something in the record needs explaining. The purpose is a short statement of what the system does and for whom. Under the EU AI Act, purpose matters more than technology: the same model can be low risk in one use and high risk in another, so write the purpose as the intended use, not as a description of the underlying model.

The lifecycle stage records whether the system is planned, in development, in production, or retired. Regulators care about this distinction. A system in production carries live obligations now; a planned system gives you time to build its record before deployment. Keeping the stage current also keeps your inventory honest, which is the point of having one.

Risk classification is the step that drives everything downstream. The classification you record determines which compliance modules the platform surfaces for the system and what an eventual evidence export is expected to contain. The platform guides the classification with structured questions, but it records your answer rather than deciding your legal position for you. If the classification is contested or unclear, record your current view, note the open question in the system record, and confirm the position with a qualified adviser.

Why maintain a formal inventory at all? Because an inventory is the starting condition for any credible AI governance programme. You cannot assess, document, or answer for systems you have not listed. An inventory also converts an abstract obligation into a bounded piece of work: once the list exists, the remaining effort is a known number of assessments rather than an open question.

You can register as many systems as your tier allows. Each system keeps its own module runs, attached documents, and audit trail, fully separated from its siblings. That separation is deliberate: when you later export a record for one system, it contains that system's history and nothing else, which is what an external reviewer wants to see.

A registered system is not locked. You can edit the name, owner, purpose, lifecycle stage, and classification later, and every edit is written to the audit trail with who changed what and when. If a system is decommissioned, set its stage to retired rather than deleting it; the record of a retired system is still part of your compliance history.

The practical habit that makes the feature work: register a system when it is planned, not when it ships. The earlier the record exists, the more of the system's life your audit trail covers.

To change the owner of an AI system — or edit any of its other details — open AI Systems, click the system you want, then click Edit. The edit form opens with the system's current values; set or change the Owner field to the person accountable for that system and click Save changes.

The same form is where you correct the name, purpose, description, vendor, modality, lifecycle stage, and the jurisdictions the system is deployed into. Edit is available on any system that has not been retired, including one still in draft.

Saving re-runs the classification modules immediately, so the register reflects the new details straight away. If something you changed affects the system's classification, the evidence locked under the previous record is marked superseded rather than left to silently disagree with the new one. Every edit is written to the audit log against the person who made it, which is why the change has to be made by a signed-in user rather than on their behalf.

You need a role that may write to the register — Admin or ASO. A Viewer or DPO role can read the system but the edit is refused, so if the Edit form will not save for you, your role is the first thing to check.

Two different things are called owner, and it is worth keeping them apart. The system owner is the person accountable for one AI system's compliance record — it is a governance field on the system, and naming someone there grants them no access. An in-app role (ASO, Admin, DPO, Viewer) is what actually controls who can sign in and change things, and you manage that under Team in settings.

Question 6

How do I run a compliance module and get a report?

Accepted Answer

To run a compliance module, open a registered AI system, pick a module from the module list, and start a run. The module asks you a structured set of questions about the system. You can save at any point and resume later. When you finish, the engine scores your responses and produces a report with findings, gaps, and recommended remediations.

A module is a structured assessment of one compliance topic, built from the requirements of the regulatory framework your workspace runs. One module might cover risk management, another data governance, another human oversight. Working topic by topic keeps each run short enough to finish and makes the output specific enough to act on. The list of modules you see for a system depends on the system's risk classification, so a lower-risk system shows a shorter list than a high-risk one.

The questions are written for the people who actually know the system: the product owner, the engineers, the person who manages the data. You do not need a legal background to answer them. Where a question uses a regulatory term, the module explains it in plain language first. Answer from what your organisation actually does today, not from what it intends to do, because the value of the report depends entirely on the honesty of the input.

Save-and-resume matters in practice because a module run is rarely one sitting. Typically one person starts a run, discovers that three answers belong to a colleague, and parks it. The run keeps its partial state until someone finishes it. Nothing is scored or reported until the run is complete, so a parked run never produces a misleading half-report.

The report has three parts. Findings state what the assessment established, both where you meet the requirement and where you do not. Gaps are the specific points where your current practice falls short of what the framework asks. Remediations are concrete recommended actions to close each gap. The report links every finding back to the answers that produced it, so a reviewer can see the reasoning, not just the conclusion.

Each run is versioned and stored against the system permanently. This is the feature that turns a one-off assessment into a compliance history. When you fix a gap and run the module again, the previous run is not overwritten; both runs sit in the record, and the difference between them is your documented progress. Regulators and auditors respond well to that shape of evidence, because it shows a working process rather than a snapshot prepared for the audit.

Completed runs feed directly into the system's evidence export, so there is no separate step where you re-describe the work for an external audience. The run you did is the evidence.

Two practical recommendations. Run your first module on your most important production system rather than an easy one; the gaps you find there are the ones worth finding early. And schedule re-runs after remediation work rather than leaving the last run as the record, because a report that ends on open gaps understates work you have since done.

Question 7

How do I generate an evidence pack and share it with an ACB?

Accepted Answer

To produce an evidence pack, open the AI system and click Generate evidence pack. The platform assembles the system's completed module runs, attached artefacts, and a tamper-evident audit trail into a single export. You can then share it with an Accredited Compliance Body (ACB) or the DFSA through a time-limited, access-controlled share link, or download the pack and send it yourself.

The pack exists because assessment work only counts when it can be shown. DIFC Regulation 10 anticipates certification and supervisory review, and both depend on an organisation producing its compliance record in a form a third party can examine. Assembling that record by hand from tickets, documents, and spreadsheets is slow and error-prone. The generate step replaces that assembly with an export built from work already recorded in the platform.

What goes in is exactly what the system's record contains: each completed module run with its findings and scores, the documents you attached to the system, and the audit trail of who did what and when. Nothing is written for the occasion. If the record has gaps, the pack shows the gaps. That property is deliberate, because a reviewer who finds one polished inconsistency will distrust the whole submission, while a record with honest gaps and visible remediation reads as a working compliance programme.

The audit trail is tamper-evident, meaning the export lets a reviewer verify that entries were not altered after the fact. For a certification exercise this is the difference between asserting your history and demonstrating it.

Sharing is a separate, deliberate act. Generating a pack does not disclose anything. When you are ready, create a share link from the evidence page. The link is time-limited, so access lapses on the date you set, and access-controlled, so it reaches the reviewer you intended rather than anyone holding the URL. If your ACB prefers to receive files directly, download the pack and send it through whatever channel they specify; the content is the same either way.

Every generation and every share is itself recorded in the audit log. This gives you a defensible answer to a question that arises more often than expected: what exactly did we disclose, to whom, and when? If a supervisory conversation later turns on what a reviewer had seen at a given date, your log answers it precisely.

Packs are point-in-time exports. A pack generated today reflects the record today, and later work does not retroactively change an export already shared. When your record improves materially, generate a fresh pack rather than expecting an old link to update.

The practical rhythm that works: generate a pack after each significant round of module runs, review it internally as if you were the ACB, close what you find, and only then share externally. The internal read-through costs an hour. Discovering the same issues during certification costs a great deal more.

Who should hold the task depends on your setup. Generating and sharing sit with the roles that manage the system's record, so the compliance lead usually owns the rhythm while the system owner supplies the missing artefacts a read-through exposes. Keeping those two in the same review session shortens the loop from found gap to closed gap considerably.

Question 8

How do I manage team members and their in-app roles?

Accepted Answer

To manage your team, open Team (or Members) in settings. Invite a colleague by email and assign an in-app role: Owner, Admin, Member, or Viewer. You can change a person's role or remove them at any time, and every change is written to the audit log.

The four roles map to how compliance work is actually distributed in an organisation. An Owner has full control, including billing and the ability to manage other Owners; this is the person answerable for the workspace itself, usually whoever set it up or the budget holder. An Admin manages systems, module runs, and evidence, but not billing; this fits the compliance lead or programme manager running the day-to-day work. A Member works on the systems assigned to them, answering module questions and attaching documents; this fits engineers, product owners, and data specialists who hold the facts a module asks about. A Viewer has read-only access; this fits internal audit, legal reviewers, and senior stakeholders who need to see the state of the work without the ability to alter it.

Assigning the narrowest role that lets a person do their job is worth the small effort. It follows the least-privilege principle that underlies most security standards, and it keeps your audit trail meaningful: when a record shows who changed a classification, the role model is what makes 'and they were authorised to' part of the same answer. A governance record maintained in a workspace where everyone can edit everything is weaker evidence than the same record with enforced separation.

Invitations work by email. The colleague receives a link, creates their account or signs in, and lands in your workspace with the role you set. Until they accept, the invitation is pending and grants nothing. The number of seats available depends on your subscription tier.

Role changes take effect on the person's next request. There is no delay you need to plan around, and no session where someone keeps yesterday's permissions. Removal works the same way: a removed person loses access at once, while everything they did remains in the record attributed to them. Work history is never rewritten by a departure, which is exactly what an auditor expects.

Two rules protect the workspace from lockout and privilege mistakes. Only an Owner can manage billing, so a compromised or mistaken Admin account cannot change your plan. And only an Owner can promote, demote, or remove other Owners, so control of the workspace cannot drift downward by accident.

A practical suggestion for first setup: create one Owner, make your compliance lead an Admin, add the people who hold system knowledge as Members, and add internal audit as Viewers. Review the list periodically, because access reviews are themselves a control most frameworks expect, and the audit log gives you the change history to support one.

When someone leaves the organisation, remove them the same day their access elsewhere is revoked, and reassign any AI systems they owned so each record keeps a live, answerable owner. An inventory whose owners have all moved on is a common audit finding, and it is entirely avoidable with a leaver step that takes under a minute.

Question 9

How do I manage billing, invoices and my plan?

Accepted Answer

Billing lives on the Billing page, which only the workspace Owner can see. From there you can check your current subscription tier, upgrade or downgrade your plan, update payment details, and download invoices. If you cannot see the page, you are not the Owner; ask the person who set up the workspace.

Restricting billing to the Owner is a deliberate control, not an inconvenience. Plan changes have financial consequences and change what the whole workspace can do, so they belong with the single accountable role rather than with anyone who happens to have access. It also means your finance team has one named person to talk to about the subscription.

The page shows your tier and what it currently allows: the number of AI systems you can hold, the seats you can fill, and the modules unlocked. Upgrades apply immediately. The moment an upgrade payment is confirmed, the higher limits are live, with no migration and no downtime, so you can raise your tier on the day you actually need the capacity rather than in advance. Downgrades are scheduled for your next renewal instead of applying at once. This protects you from losing access to records mid-cycle, and it gives you time to archive systems if your inventory exceeds the lower tier's limit.

Invoices are available on the page as downloads, so your finance team can pull what they need without asking you to forward emails. Each invoice reflects the plan and period it covers. Paid invoices unlock the corresponding tier features automatically; there is no manual activation step after payment.

If you pay by card, activation follows the payment provider's confirmation, which is usually immediate. If you pay by bank transfer, your plan activates once the payment is marked paid, which depends on the transfer arriving and being reconciled. If a transfer has been sent but the plan has not activated, the payment is most likely still pending reconciliation rather than lost.

Updating payment details is done from the same page. Do this before a card expires rather than after a renewal fails, because a failed renewal can interrupt access for everyone in the workspace, and the interruption always lands at an inconvenient time.

For a billing question the assistant cannot resolve, such as a reconciliation query, a correction to invoice details, or a question about a specific charge, an Owner can request follow-up from the Billing page and the team behind the platform will respond. Include the invoice number and the date of the transaction; those two details resolve most billing questions in one exchange.

One habit worth adopting: when your compliance programme grows, review your tier against your actual inventory rather than waiting for the hard limit. Hitting a system cap in the middle of onboarding a new AI system is avoidable friction, and the upgrade that fixes it takes effect the moment you make it.

If ownership of the workspace needs to move, for example when the person who set it up changes role or leaves, transfer the Owner role before they go rather than after. A workspace whose only Owner has left cannot change its own plan or payment details until access is restored, and that recovery takes longer than a handover would have.

Question 10

How do I set up two-factor authentication?

Accepted Answer

To set up two-factor authentication (2FA), go to Account, then Security, and enrol an authenticator app. Scan the QR code with the app, enter the 6-digit code it shows to confirm the pairing, and save the one-time recovery codes you are given somewhere safe. From then on, signing in takes your password plus a current code from your app.

The reason to do this is blunt: passwords leak. They are phished, reused across services, and exposed in third-party breaches, and none of that is within your control. A second factor means a leaked password alone is not enough to open your account. For a workspace that holds your organisation's compliance record, regulatory assessments, and evidence about your AI systems, the account is worth more to an attacker than most, and the few seconds a code costs at sign-in is the cheapest control you can buy.

Any standard authenticator app works: the platform uses time-based one-time codes, which is the widely supported open standard rather than anything proprietary. The app generates a fresh 6-digit code every 30 seconds on your device. The code never travels to you over email or SMS, which removes the interception routes those channels carry.

The recovery codes deserve more respect than they usually get. They are single-use codes that let you sign in when your device is lost, broken, or reset. Treat them like cash: store them in a password manager or printed in a genuinely secure place, and never in the same place as the device they are meant to rescue you from. Each code works once and is then spent.

If you lose your device, sign in with a recovery code, then go straight to Security and enrol a new authenticator. Enrolling the new device invalidates the old pairing, so a lost phone stops being a key to your account the moment you re-enrol. If you have used most of your recovery codes, generate a fresh set at the same time.

If you are locked out with no device and no recovery codes, you are not permanently stranded, but the path is intentionally harder: a workspace Owner or the platform team can help restore access after verifying who you are. The friction there is the security working as designed. An easy bypass for you would be an easy bypass for an attacker.

There is also a compliance angle. Access control questions appear in security reviews, vendor assessments, and most governance frameworks, and 'is multi-factor authentication enforced for accounts holding sensitive records' is a standard line item. Enrolling 2FA on the accounts that manage your AI compliance record is one of those controls that costs minutes and answers a question you will certainly be asked.

The practical order for a team: the workspace Owner enrols first, because that account can change billing and membership, then Admins, then everyone else. Do it on a calm day, not during an incident. Pair the rollout with a shared note on where recovery codes belong, so nobody improvises their own storage, and check completion in your next access review. A partially protected workspace gives a false sense of cover, because an attacker only needs the one account that skipped the step.

Run DIFC Regulation 10 on every AI system you operate.

Why this is hard

How it works

Why you can rely on it

Where your data lives

Assess your AI system