Warde / Security
Your instance,
your data.
Warde is one scoped application inside your ServiceNow instance. It runs under the hosting, encryption, sign-in and backup you already have, and Warde the company holds no copy of what it does.
Where Warde runs.
- In your instance
- Everything Warde writes is in your instance’s tables. Your ServiceNow hosting, region, encryption at rest and backups apply as they do to the rest of the platform.
- No server in the path
- There is no Warde middleware and no connection from Warde into your instance. Every outbound call starts in the instance.
- No new sign-in
- People sign in to ServiceNow as they do today, with your single sign-on and multi-factor rules. Warde adds no sign-in path.
- Nothing loaded from outside
- The package carries no third-party code. Its pages load no script, font, image, analytics tag or tracking call from outside the instance.
- No paid subscriptions
- No IntegrationHub, Now Assist, ITOM or Performance Analytics needed.
- Platform tables left alone
- Warde does not customise ServiceNow’s request and task tables. Approvals are the platform’s approval records and manual work is its catalog tasks.
Where data goes.
Four destinations, and nothing else leaves the instance.
- Your identity systems
- Access requests, removals and conflict checks go over HTTPS to the systems you connect, directly or through your MID Server. Each is told who the change is for, what to grant or remove, and why.
- Your own people, by email
- Notifications through your instance’s outbound mail: reviews due, access about to end and changes to bundles.
- A person’s browser
- A spreadsheet of access that person can already see on screen, when they export it from My Access.
- One number to Warde
- Warde is priced per user, so once a week a production instance sends its name and a count of people holding the requester role. No name, email or identifier of any person goes with it. Development and test instances send nothing.
What Warde does not do.
No telemetry
No usage analytics, no error reporting service, and no call to any AI service from the base application.
No standing access
Warde holds no access to any customer instance. Support asks for exports first, and any diagnostic access is a named, time-boxed account on a sub-production instance, granted by you and removed on close.
Who can see and change it.
- Scoped roles
- Five Warde roles: administrator, requester, fulfiller, lifecycle integration and AI client user. Every access rule names one of them.
- Scoped administration
- Once you remove the starting grant, the platform admin role confers nothing in Warde. Only named Warde administrators run it.
- Checked on the server
- Every check a form makes in the browser is made again on the server. A grant for someone without the requester role is refused, whatever wrote it.
- Credentials in platform aliases
- Endpoints and secrets live in ServiceNow Connection and Credential aliases, filled in by your administrator. Warde ships none, and refuses any connection that is not HTTPS.
- One way in
- The only inbound interface is the lifecycle API your HR or identity system calls, which needs its own role and checks every value it is sent.
- APIs as the person
- The Warde API for AI assistants runs every call as the person signed in, with their own token and only what their roles allow. MCP and the Warde API
An audit trail that cannot be edited.
Append-only
Every access change is written to an audit table with no create, write or delete rule. Only Warde’s own code writes it, and no Warde code deletes a row.
Names kept
Each row keeps copies of the person, account and access names, and who asked, for whom, why and every approval, so it still reads correctly after a rename or a leaver.
Seven years by default
Audit rows are kept for seven years by the platform’s table cleaner. Your administrator can change the period in Guided Setup.
Clean logs
Log lines name records by id and never carry a payload, a token, approval text or a person’s name or email. A check on every change holds the code to that rule.
How it is built and supported.
- Safe by construction
- No eval, dynamic script or impersonation anywhere in the shipped code. Record values are escaped wherever they reach a page, a message or an email.
- Checked before release
- Each release build is checked for credentials, connection URLs, development hosts and test records before it ships.
- Vulnerabilities
- A reported vulnerability is treated as severity 1 and assessed within one business day. Affected customers hear within two business days of confirmation, with the mitigation.
Questions from security reviews
Does Warde hold any of our data?
No. Your instance holds it, and Warde the app reads and writes it there. Warde the company holds the weekly licence count, and what you send to support.
Where does the licence count go?
To licensing.warde.app, which runs on Google Cloud in Sydney. It keeps the instance name, the product, the count and the time. Each report is signed, so it cannot be copied or changed.
What do our identity systems receive?
Who the change is for, what to grant or remove, and the request context: the request number, who asked, their reason, and each approval. Free text people type reaches the identity system, where its own retention applies.
Does Warde use AI?
The base application calls no AI service. One catalog item can be ordered in a Now Assist conversation; it ships switched off, and runs on your own Now Assist subscription if you turn it on.
Can we see the full security note?
Yes. The security architecture note answers the usual questionnaire, section by section. Ask for it.
More of Warde
Bring your security questionnaire.
We’ll walk your security team through it on a live instance.
Warde is priced per user. Book a walkthrough or get in touch for a quote.