Appian Application Security Review
In Appian, one over-privileged group grants a user its highest permission across every object it touches. We test role maps, record and field-level security, and what connected systems can reach. CREST-certified testers, fixed price from £2,270 for a 2-day single-application scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
A user who belongs to more than one group in an Appian role map is always granted their highest permission across it, never the average or the most restrictive.
An Appian user’s access is the highest permission any group they belong to was ever given
Every object in Appian, from a process model to a rule folder, is secured by exactly one role map that assigns groups to permission levels, and Appian is explicit that a user who belongs to more than one group in that role map is always granted their highest permission, never the average or the most restrictive. Deny exists precisely to override that default: it is the only way to stop a group from inheriting access it would otherwise pick up by being nested inside a more privileged one. Rule folders and knowledge centers sit above this again, since security set on a top-level folder is inherited immediately by every rule, interface, constant and integration nested inside it unless that object is given its own role map instead.
Appian’s record-level security narrows that further, filtering which rows of a record type a user sees on top of the Viewer permission that would otherwise show them every row, configured through guided security rules or a formula-based security expression. Field-level security runs alongside it to hide individual columns rather than rows, but only on record types built with Optimized or Direct Data Access, since a legacy record type supports neither and has to fall back on a showWhen parameter set by hand in every interface. Neither layer is enforced inside Appian Designer itself, so a developer testing an interface sees every row and every field regardless of what a real end user’s groups would allow.
A connected system object centralises the credentials for an external API or database so they can be reused and secured with the same object security as everything else, but a web API built on top of one carries its own risk: adding an origin to the CORS allowlist in the Admin Console also exempts that origin from Appian’s built-in cross-site request forgery protection. Whether the application runs on Appian Cloud or a self-managed installation changes where that risk sits, since Appian Cloud enforces its own TLS policy on every inbound connection while a self-managed environment is responsible for configuring TLS itself. It is the same group-and-role question we test on Mendix’s module roles, applied to Appian’s groups, role maps and record types instead.
SCOPE
What we pen test on an Appian application
Role maps: Viewer, Editor, Administrator, Deny and object-specific levels
Every object in Appian, whether a process model, an interface or a rule folder, is secured by exactly one role map assigning groups to permission levels, and most objects accept Viewer, Editor, Administrator or Deny while a process model adds Initiator and Manager on top. A user who belongs to more than one group in a role map is always granted their highest permission, so a group added for an unrelated reason can silently hand out Administrator rights if it happens to appear in that role map too. We map every role map in scope against the groups that actually hold it, the same group-based question we test on Mendix’s module and user roles.
The Deny permission and groups nested inside a more privileged one
Giving a group the Deny permission level in a role map is Appian’s way of overruling access that group would otherwise inherit by being nested inside another, more privileged group, since without Deny that nested membership grants the higher permission regardless. We test which groups in scope are nested inside others, and whether Deny was actually used anywhere it was needed rather than assumed.
Security inheritance from rule folders and knowledge centers
Rule folders and knowledge centers are top-level objects whose role map is inherited immediately by every rule, interface, constant, decision and integration nested inside them, unless that object is given its own role map instead. A change saved to the parent’s security is reflected in every inheriting child straight away, so a single role map can end up governing far more of an application than its name suggests. We test what actually inherits security from where, not just the role maps set closest to the objects in scope.
Record-level security: security rules and security expressions
Record-level security filters which rows of a record type a user can see, on top of the Viewer permission that would otherwise show every row, and it is configured through guided security rules or a formula-based security expression rather than through the object’s main role map. It is only available on record types built with Optimized Data Access or Direct Data Access with features enabled, so a legacy record type has no equivalent row-level control at all. We test the rows every group in scope can actually see, including through Appian’s own MCP Server queries, which enforce the same record-level rules for external AI applications.
Field-level security and what a locked field actually hides
Field-level security restricts specific columns in a record type to designated groups, but it behaves differently depending on where a user meets that field: an interface still displays the field with a null value, while a query on the record type omits it from its output entirely. It is never enforced inside Appian Designer, so a developer sees every field regardless of its configuration and has to test the live application to confirm the restriction actually holds. We test what a restricted field returns in every place it can be reached, not just the interface it was designed to be hidden from.
Record action security for New, Update, Delete and bulk actions
A record action such as New Case or Delete Case is visible by default to any user with Initiator permission on the underlying process model, and a related action additionally needs the user to be able to see the record itself. Security rules or a security expression can narrow that further, for example restricting a bulk edit action to a supervisor group while leaving individual record actions open to everyone with Initiator rights. We test what every record action in scope actually allows a given group to do, not just whether they can see the record it acts on.
Connected systems storing credentials for external APIs and databases
A connected system object centralises the authentication details for an external API or database, from a plain HTTP or OpenAPI connection to prebuilt templates for Salesforce, SharePoint, Snowflake and other named platforms, so the same credentials can be reused across every integration built on top of it. Object security controls who can view or edit those credentials during development, separately from whoever is allowed to use the connected system in a running application. We test who can reach a connected system’s stored credentials, and what every integration built on one is actually authorised to do.
Web APIs, rule inputs and the CORS allowlist
A web API built in Appian takes its input through query parameters, headers or a request body instead of the rule inputs an expression rule would use, and exposes that logic to any external system able to reach its endpoint. Adding a site to the CORS allowed origins list in the Admin Console also exempts that site from Appian’s built-in cross-site request forgery protection on POST, PUT, DELETE and PATCH web APIs, which is easy to overlook when the allowlist entry was only meant to fix a browser error. We test every web API and CORS entry in scope against what it was actually meant to allow.
Appian Cloud environments, the subscription administrator and system administrators
An Appian Cloud environment’s URL, subscription administrator and first system administrator account are all set from the details in your legal agreement, and creating a further system administrator hands that account full control of the environment, which is why Appian Support verifies the request before it goes ahead. We test who holds system administrator access on every environment in scope, and whether that access matches what each admin still needs.
Appian Cloud versus a self-managed installation
Appian Cloud enforces its own TLS policy on every inbound connection, including user requests and external systems calling a web API, while a self-managed installation is responsible for configuring its own TLS instead. Deploying a package between environments also has limits either way, since certain environment-specific settings such as API keys and certificates are never included in a deployment package and have to be set independently in each environment. We test the deployment you actually run, Appian Cloud or self-managed, against the TLS and credential handling it depends on.
OUR PROCESS
Appian Application Security Review: From Scope to Attestation
Group, Role Map and Record Type Mapping
We catalogue every group, role map, record type and connected system in the application, and confirm whether it runs on Appian Cloud or a self-managed installation.
Group-Based Access Testing
We test from accounts in every group in scope, checking what each one’s role maps, record-level security and field-level security actually allow against live data.
Record Action, Expression Rule and Connected System Testing
A CREST-certified tester works through every record action’s security configuration, expression rule and rule input, and every connected system’s stored credentials and exposed web APIs.
Reporting and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Appian pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Appian Application Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Appian For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Appian Application Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Appian application?
A login for each group in scope, from a standard end-user group up to an Administrator role map entry, is enough to start. Read access to Appian Designer speeds up confirming role maps, security rules and connected system configuration, though it is optional.
Will this touch our live data?
We test read-only against production by default. Where proving a create, update or delete finding needs real records, we agree a sandbox environment or specific test data with you first, and anything we create during testing is documented and removed afterwards.
Is this Appian Cloud or a self-managed installation?
Both. Appian Cloud enforces its own TLS policy on every inbound connection, while a self-managed installation is responsible for its own TLS configuration, and we scope the test to your groups, role maps, record types and connected systems either way, not to Appian’s own infrastructure.
Does Appian have a policy for customers testing their own application?
Yes. Appian’s own documentation requires customers to give notice of their penetration and vulnerability testing at least three business days in advance through a support case, with the assessment rules set out in Appian’s own knowledge base article. We confirm this notice, and any Appian Cloud-specific restriction, with you before testing starts.
What is out of scope?
Appian’s own platform code and Appian Cloud’s shared infrastructure, other customers’ environments, and denial-of-service testing are all out of scope. We test the groups, role maps, record types, process models, expression rules and connected systems you have built.
How long does an Appian application test take?
A single application sits in our 2-day single-application scope, rising with the number of process models, record types, connected systems and groups in scope. We confirm the exact day count once we have seen the application.
Do you need our Appian Designer access or just a running application?
A running application with test accounts in every relevant group is enough to start. Designer access speeds up root-causing anything we find, particularly around role map inheritance and rule inputs that are not visible from outside the application, but it is not required.
Are your testers CREST certified?
Yes. Every Appian engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Appian application
In Appian, one over-privileged group grants a user its highest permission across every object it touches. We test role maps, record and field-level security, and what connected systems can reach. CREST-certified testers, fixed price from £2,270 for a 2-day single-application scope, quoted within 24 hours.
