Security
Secure by design
We are transparent about what we hold and how we protect it. Here is where your data lives, how it is secured, and what keeps the paging path up when everything else is down.
A request enters in Germany, is written in Ireland, and is copied to a read-only replica that serves US customers. Only one of the three keeps anything.
a request arrives
Germany
Processes requests. Keeps nothing.
serves traffic
writes land here
Ireland
Processes requests and holds the primary store.
serves traffic
replicated, read only
United States
Read replica. Serves read traffic to US customers for lower latency. Not on the write path.
serves traffic
live request and write pathreplication to read-only replica
The platform
Encrypted, isolated, and up
Two promises about the same platform. Your data is encrypted before it is written and stays encrypted everywhere it is copied; and the paging path stays up, because an on-call platform that is unavailable during an outage is worse than none at all — your team assumes silence means nothing is wrong.
Tenant isolation
ITOC360 is multi-tenant. Every record carries a workspace identifier and access is filtered on it at the database layer, not only in application code — so a query that slips past a check in the application still cannot return another organization's rows.
In transit
Every connection is encrypted: web app, mobile apps, REST API, inbound integration webhooks and outbound notifications. Plain HTTP is redirected, never served.
At rest, and in backups
The Irish primary store, object storage and the United States read replica are all encrypted, and so are the backups — with restores tested rather than assumed.
Integration credentials
The API keys, webhook secrets and chat tokens you give us to connect Zabbix, Prometheus, Slack and the rest are encrypted separately and never returned in plaintext. Once saved, a credential can be replaced but not read back.
No single point of failure
Every tier runs redundantly across separate availability zones. No individual node, queue or database instance can stop alert delivery.
Alerts are never dropped
Incoming alerts land in a durable queue before any processing. A downstream failure delays and retries; a failure on one notification channel escalates to the next rather than ending the attempt.
Regional failover
If the Irish store becomes unavailable we fail over to the encrypted read replica in the United States. Recovery objectives are documented and available on request.
Watched from several regions
Synthetic tests run around the clock from separate regions and exercise the whole path — ingest, correlate, escalate, deliver — not just whether a page loads.
Our own on-call
ITOC360's engineering rotations run on ITOC360. When our monitoring fires it pages us down the same escalation path we built for you, which is the only version of this claim worth making.
Remediation
How quickly we fix what we find
Findings are triaged on severity and tracked to closure — our own tooling and outside reporters alike.
- Critical
- Triaged within
- 24 hours
- Resolved or mitigated within
- 7 days
- High
- Triaged within
- 3 days
- Resolved or mitigated within
- 30 days
- Medium
- Triaged within
- 7 days
- Resolved or mitigated within
- 90 days
- Low
- Triaged within
- 30 days
- Resolved or mitigated within
- Next planned release
Getting in
Identity and access
Authentication runs on a dedicated identity layer rather than on login code written by hand inside the product. Sign-in, session handling, token rotation and password storage are the parts of an application that teams most often get subtly wrong, so we do not maintain our own version of them. The controls below come with that layer.
Passwords
Never stored. Only a per-user salted bcrypt hash is kept, so a database copy does not yield usable credentials.
Multi-factor authentication
Time-based one-time codes (TOTP), enrollable by any user and enforceable across a whole workspace by an administrator.
Single sign-on
SAML 2.0 and OpenID Connect, so access follows your identity provider. Removing someone there removes them here.
Short-lived sessions
Access tokens expire in minutes and are renewed by rotating refresh tokens. A stolen token has a narrow window, and reuse of a rotated token invalidates the session.
Role-based access
Permissions are assigned by role across viewing, editing schedules, changing escalation policies and administering the workspace.
How we build
Code and dependencies
Security review is part of the pipeline rather than an event that happens twice a year. Code cannot reach production without passing through the checks below.
Peer review
Every change is reviewed by another engineer before it merges. Direct pushes to the production branch are blocked.
Static analysis
Runs on every commit, flagging injection paths, missing authorization checks and unsafe patterns before merge.
Dependency scanning
Runs continuously against the full dependency tree. Known vulnerable packages are surfaced with a fix path rather than a report nobody reads.
Secret scanning
Commits containing credentials, tokens or private keys are blocked at the gate, and anything that reaches history is treated as compromised and rotated.
What it takes for our own staff to reach your data
Most vendor questionnaires ask about attackers. The more useful question is what our own people can reach — so here is every gate between an ITOC360 engineer and a production record, in the order they meet them.
- Step 1
Named, by role
Production access is granted to specific engineers by role, not to everyone on the team, and is removed when the role changes.
- Step 2
Multi-factor, everywhere
Every internal system — source control, cloud consoles, the production estate — requires a second factor. There is no path in that a password alone opens.
- Step 3
Logged as it happens
Production access is logged, and the access list is reviewed on a recurring schedule rather than when someone remembers.
- Step 4
Nothing leaves with them
Customer data is not exported to local machines or into development and staging environments. Non-production environments use synthetic data.
- Step 5
Support asks first
Support engineers do not browse workspace data. Access to your workspace for troubleshooting happens at your request and is recorded.
Subprocessors
Providers we depend on
ITOC360 is not built entirely by ITOC360. Hosting, telephony, email delivery and a handful of other services sit underneath it, and each of them signs a data protection agreement before it handles anything.
Cloud infrastructureRuns the compute in Germany and hosts the encrypted stores in Ireland and the United States.
IdentitySign-in, session and token handling, multi-factor enrollment, password hashing.
Voice and SMSPlaces the calls and sends the messages that reach your on-call engineer. Sees the destination number and whatever alert text the message carries.
Push and emailMobile push notifications and transactional email such as invitations and password resets.
AI processingGenerates correlation, summaries and suggested next steps. Receives incident content for the length of the request only, and is contractually barred from training on it or retaining it.
Platform telemetryOur own error tracking and performance monitoring. Sees application errors and timing data, not the contents of your incidents.
BillingSubscription payments. Card details are submitted to the payment provider directly and never reach ITOC360.
Each provider receives only what its function requires — a carrier gets a number and a message, not a copy of your workspace. Write to security@itoc360.com for the current named list, with each provider’s role and the countries it operates from.
Shared responsibility
What you control
We secure the platform. You decide who inside your organization can reach it and what you send us — and alert payloads arrive as your monitoring writes them, hostnames, stack traces and all. Trimming sensitive fields at the source is the cheapest control you have.
ITOC360 secures
- The application, the API and the infrastructure under them
- Encryption everywhere your data is written or copied
- Isolation between workspaces
- Availability of the paging path, and response when it is threatened
You configure
- Who is in your workspace and what role they hold
- Whether SSO and MFA are enforced for your team
- The scope of the API keys and credentials you connect, and when you rotate them
- What ends up in alert payloads, and offboarding at both ends
Reporting a vulnerability
If you have found a security issue in ITOC360, we want to hear about it before anyone else does. Fill in the form below, or write to security@itoc360.com if you would rather use email. Either reaches the same people.
Before you send it
How we handle a report
- Safe harbourWe will not pursue legal action against researchers who act in good faith, stay within their own test account, avoid degrading service for others, and give us reasonable time to fix the issue before publishing. Please do not access, modify or download data belonging to anyone else while testing.
- What happens nextWe acknowledge within two business days, from a person rather than an autoresponder. We reproduce the issue, assign a severity and tell you what we concluded even where we disagree with your rating, then fix it on the timetable above with progress updates rather than silence. Credit is yours if you want it and withheld if you do not.
- Out of scopeScanner output with no working proof of concept, missing headers with no demonstrated impact, social engineering of our staff or customers, denial of service, and issues in third-party services we do not control.
Rated on the platforms buyers check
Questions reviewers ask
Where is our data processed and stored?
Processing happens in Germany and Ireland, both inside the EU. Data at rest is held in Ireland only; the German region runs compute and persists nothing. An encrypted read replica in the United States is kept up to date, serves read traffic to US customers, and is not on the write path.
Do you use our data to train AI models?
No. Your incidents, alert payloads, schedules and postmortems are not used to train models, ours or anyone else's. Where we send data to an AI provider to generate a summary or a suggestion, that provider is contractually restricted from training on it or retaining it beyond the request.
Is ITOC360 multi-tenant, and how is our data isolated?
It is multi-tenant with logical isolation. Every record is scoped to a workspace and filtered at the database layer through row-level policies, underneath the application's own permission checks.
What happens if a region goes down?
If the Irish store becomes unavailable we fail over to the encrypted read replica in the United States. Within each region, redundancy across availability zones means most component failures are absorbed with no interruption to alert delivery at all. Recovery time and recovery point objectives are documented and available on request.
Do you support SSO and enforced MFA?
Yes. SAML 2.0 and OpenID Connect connect ITOC360 to your identity provider, and administrators can require multi-factor authentication across the workspace.
Who at ITOC360 can access our workspace?
Production access is limited to named engineers by role and is logged. Support engineers access a workspace only when you ask them to, and that access is recorded.
Which third parties can access our data?
A short list of infrastructure, identity, telephony, email, AI and billing providers, each under a data protection agreement and each receiving only what its function requires. We will send you the current named list, with roles and locations, if you ask at security@itoc360.com.
How are the credentials we connect protected?
Integration credentials are encrypted separately from ordinary data and are never readable through the API or the interface after they are saved. You can replace or revoke one at any time, which takes effect immediately.
Can we export or delete our data?
Yes. Incident history, schedules and audit records can be exported through the API at any time. On request, we delete customer data from the primary store and the read replica, and from backups on their normal expiry cycle.
Do you require access to our infrastructure?
No. ITOC360 receives alerts from your monitoring systems over outbound webhooks or API calls that you configure. We do not install agents in your environment, we do not need inbound network access, and we do not connect to your source control or deployment pipelines.
Can we get your security documentation for our review?
Yes. Write to security@itoc360.com with the questionnaire or documents you need and we will work through them with you.
Questions a reviewer still needs answered?
Send them to security@itoc360.com and we will answer in writing.