ISO 9001 — Quality Management System
Processes executed in a defined, measurable and auditable way.
01
Certificates and scope
The PDFs of four management system certificates are downloadable below. The certification body, the scope statement and the validity date are printed on the certificate itself — we deliberately do not repeat the date here, because an expired date left sitting on a web page misleads more than the certificate itself ever could. Read the date from the document.
ISO 27001 — Information Security Management System
Asset classification, access control, risk management and incident management framework.
ISO 22301 — Business Continuity Management System
Disruption scenarios defined in advance, recovery plans exercised and reviewed.
ISO 42001 — Artificial Intelligence Management System
Governance across the AI lifecycle: purpose definition, risk assessment, human oversight and traceability.
Not a certificate — a legal obligation
Turkish data protection law (KVKK) is not a certification subject; it is a statutory obligation handled through separate documents. We keep those out of the certificate list on purpose: KVKK information notice, retention and destruction policy, data subject application form.
—
Certificate Scope & Validity
Scope, validity period and verifiable document link for each ISO certificate.
ISO 27001
Information Security Management
Scope
361 platform, support processes and management systems
Valid
2026-03-01 — 2029-03-01
ISO 27701
Privacy Information Management
Scope
Personal data processing activities in addition to ISO 27001 scope
Valid
2026-03-01 — 2029-03-01
ISO 9001
Quality Management
Scope
361 platform development, deployment and support services
Valid
2026-03-01 — 2029-03-01
ISO 20000-1
Service Management
Scope
365/7/24 support services and incident management processes
Valid
2026-03-01 — 2029-03-01
02
Data flow: the gates a request passes
A security claim is only auditable once the flow is visible. The sequence below is identical every time a user asks a question or an automation fires. A local model and a cloud model pass through the same gates — the gate does not change with the model.
01
Request and identity
Every request arrives with the identity and role of the signed-in user. There is no anonymous AI call.
02
Authorization context
Role-based access control and row-level security apply to AI as they do to people. Fields are filtered by role; a field the user cannot see is never sent to the model.
03
Inbound gate
GuardrailPipeline: PII, prompt-injection and cost detectors inspect the request. Violations are written to the audit trail.
04
Model routing
Work goes to the model you chose: 361 Local running inside the machine, or a provider you enabled. With localOnly on, cloud models are not listed and are categorically refused if requested.
05
Tool call
When the model calls a tool, the permission policy applies. Risky tools route the flow to human approval; without approval nothing executes.
06
Outbound gate
The answer returns through the same pipeline: PII masking and hallucination checks can be enforced on output as well.
07
Audit trail
Agent execution, tool call, data access, data modification, approval decision, configuration change, guardrail violation, data export and deletion — all recorded immutably.
08
Observability
Traces, metrics and logs are collected via OpenTelemetry and can be wired into your existing observability stack.
Why this matters
In an AI deployment the real risk is not what the model says but what it can reach. Because the authorization context is established at step 02, no matter how capable the model is it cannot see data beyond the requesting user's permissions. The long-form version lives in topics three and four of the IT Review Pack.
03
Tenancy — where isolation is enforced
"Your data is isolated" says nothing on its own; the question is which layer enforces it. On shared infrastructure, isolation is not one control but five separate ones.
Storage
Usage, cost and configuration data are held in each tenant's own directory. One tenant's record cannot be read from another.
Encryption
Connection details and provider keys are encrypted per tenant with AES-256. Nothing is stored in plaintext.
Integrations
Integration connections are isolated per tenant. Each organisation sees and uses only the connections it defined; there is no shared connection pool.
Event delivery
Channel events carry tenant scoping: an event is delivered only to subscriptions in its own tenant and cannot spill into a neighbouring one.
Cryptographic separation
Every installation has its own RSA-2048 key pair. Entitlements travel in a manifest signed for that installation; another installation's manifest is not valid.
Authorization
Role-based access control and row-level security apply to both people and AI. Isolation does not stop at the storage layer; it continues inside the query.
If you would rather not share infrastructure at all
If shared infrastructure does not fit your policy, the tenancy discussion closes before it starts: on-premise and air-gapped deployments share nothing. The comparison is on the Deployment Models page.
04
Encryption: in transit and at rest
In transit
All traffic is encrypted with TLS 1.3. Outbound calls and inbound webhooks carry signature verification.
At rest
Stored data is encrypted with AES-256. Provider and connection secrets are additionally held encrypted per tenant.
API keys
Keys issued by the platform are stored as hashes; the clear value is never kept. Lose a key and it cannot be recovered, only reissued — not a shortcoming but the direct consequence of how it is stored.
The path that needs no transport security
With 361 Local the model runs inside the machine, so no prompt, document or embedding leaves it. The transport question closes because there is no transport.
05
Key and access management
How a key is stored matters as much as how it is rotated and who may use it. All four are defined.
Rotation
API keys can be rotated with a transition window in which the old and the new key are both valid, so integrations move over without a break. When the window closes, the old key is invalidated.
Usage constraints
Per key you can define an IP allow-list, a per-minute rate limit and a daily quota. A leaked key is unusable from outside the defined network.
Provider keys
Cloud AI provider keys are managed centrally, encrypted per tenant and never returned to the interface in clear text. Even in a hybrid deployment these keys do not reach the client.
Installation identity
Each installation holds its own RSA-2048 key pair and entitlements travel in a signed manifest. One installation's manifest will not run on another.
Running without keys at all
The local runtimes (embedded llama.cpp, Ollama, LM Studio) need no provider key — with no secret to manage there is no secret to leak.
Authentication types
Six types are supported for outbound connections: none, Basic, Bearer, API key, OAuth 2.0 (three flows) and Digest.
06
Backup, retention and continuity
Backup scope and retention period are two different questions: the first is "can I get it back", the second is "how long should I keep it". Both are configurable; the defaults are below.
Backup scope
What is needed to bring an installation back:
- the business database,
- the AI configuration directory (agents, prompts, automations, provider definitions),
- knowledge bases and the vector store,
- local model files — backed up separately in on-premise and air-gapped deployments, because they cannot be re-downloaded.
Retention — defaults
Adjustable to your policy; these are the out-of-the-box values:
- general data retention: 90 days,
- conversation history: 30 days,
- log records: 90 days,
- automatic deletion of expired data: off by default — turning it on is a deliberate decision.
Deletion and undo
A deletion request starts a 30-day undo window; afterwards deterministic anonymisation is applied and the record identity is severed irreversibly. Related fields in audit records are masked — the audit trail itself is not deleted.
Runtime resilience
The local model runs in a separate process; a model crash does not stop the platform, and a continuously restarting process cannot tie the system up. Schema changes do not require a restart. When connectivity drops, the offline queue de-duplicates requests: within a 24-hour window a resent request does not create a second record.
RPO and RTO — no figure on this page, and here is why
Recovery point objective (RPO) and recovery time objective (RTO) depend on the deployment model you choose, your backup frequency, your hardware and your data volume. Publishing one number for everyone would produce a commitment that is wrong for your installation, so we publish none.
Once the deployment model and backup plan are settled, RPO/RTO targets are measured during the POC and stated in writing in the service agreement. The business continuity framework is operated under the ISO 22301 certificate.
07
Subprocessors
The answer to the subprocessor question changes fundamentally with the deployment model. Instead of one list, here is what holds in each model.
On-premise and air-gapped
There are no subprocessors. With localOnly on, no prompt, document or embedding crosses the organisational boundary; with nothing leaving, there is nothing being processed outside.
Cloud and hybrid
The subprocessor set consists of the providers and channels you enable. The platform supports 17 AI providers and 44 adapters across 8 channel families, but which ones are switched on is your decision — and no data reaches a provider you have not enabled.
Why there is no fixed list here
We do not publish a generic subprocessor list, because the list differs from installation to installation: one customer runs the local runtime only, another has two cloud providers and three channels enabled. An "average" list would be wrong for both.
For your installation, the name, function, data category and data residency of every active hosting, AI provider and channel subprocessor is provided in writing as an annex to the agreement, and any change to that set is notified in advance. We will also share it during evaluation on request — contact us.
08
Incident notification
An incident can only be noticed if it was recorded first. The technical foundation and the process side are stated separately.
Detection — technical foundation
The immutable audit trail records ten event types: agent execution, tool call, chat message, data access, data modification, approval decision, configuration change, guardrail violation, data export and data deletion. Guardrail violations are separately queryable. Traces and metrics are collected via OpenTelemetry.
Notification — process
Who is notified, through which channel and within what time is defined in the service agreement. Where an event falls within the scope of a personal data breach, the statutory notification duties under Turkish data protection law apply in addition — those are not contingent on the contract.
Two things this page does not contain
We do not publish incident history. Contracted customers receive written reports on incidents affecting their own installation; there is no public incident log.
There is no "we have never had an incident" claim either. Unless it is verifiable, a sentence like that produces risk rather than trust — so we don't write it.
09
Responsible disclosure
If you have found a security issue, reach us before you publish it. We will assess it, fix it, and credit you if you wish.
Where to report
Email: info@361.com.tr — putting "Security report" in the subject line is enough.
The machine-readable equivalent is published in RFC 9116 format: /.well-known/security.txt
What we expect in a report
- the affected address, endpoint or screen,
- steps to reproduce,
- observed impact and any evidence (screenshot, request/response),
- that the finding is not made public until a fix has shipped.
Boundaries while testing
- do not access, download or modify other users' data,
- do not run tests that degrade the service, including load or denial-of-service testing,
- social engineering and physical access attempts are out of scope,
- if you obtain access, stop and report rather than going deeper.
What we do
We acknowledge receipt, reproduce, assess impact and fix. We keep you informed throughout and will credit you as the reporter if you want. We will not pursue legal action over good-faith research conducted within these rules.
Two things we do not have yet
There is no paid bug bounty programme. We also publish no committed first-response time — we would rather state nothing than state a target we cannot hold. When either changes, this section and security.txt will be updated together.
10
Where the detail lives
This page is an entry point; each topic is written once, in depth, on its own page.
Security architecture
Access control, guardrail detectors, audit trail, observability and data residency with 361 Local.
IT Review Pack
Every question IT and security teams ask before purchase, in eight topics, printable.
Deployment Models
SaaS, private cloud, on-premise and air-gap — what works, what does not, who owns what.
Data ownership
Exporting your data, resilience to interruption, the right to delete and the four steps of an exit.
Local AI field guide
Hardware table, bundled model set, the local stack and the "local or cloud" decision table.
Legal notices
Information notice, retention and destruction policy, data subject applications, explicit consent and AI user information.