One of our sales representatives will contact you shortly.
Enterprise security is not a feature list. It is a management system: documented controls, scoped ownership, third-party audits, evidence you can test, and failure modes that are engineered, measured, and rehearsed.
InEvent positions its security program around formal assurance (SOC 2 Type II, GDPR-aligned privacy controls, and ISO 27001 certification statements) and operational transparency (published SLA, RTO/RPO targets, and vulnerability remediation timelines). (InEvent)
This page is written for vendor risk assessments where the “red pen” is looking for: scope, control intent, implementation detail, audit artifacts, and the exact evidence to request. It maps common security-review questions to ISO/IEC 27001:2013 Annex A control families, then ties those to the platform and governance statements InEvent publishes (security, GDPR, and trust pages) and to the standard artifacts enterprise buyers expect: ISO certificate, Statement of Applicability (SoA), SOC 2 report, pen test executive summary, vulnerability management SLAs, and incident response procedures. (InEvent)Compliant is an internal claim: “We follow ISO principles.” It is not, by itself, a third-party attestation.
Certified is externally validated: a registrar audits your Information Security Management System (ISMS) against ISO/IEC 27001 requirements. The output is a certificate with:
Scope statement (what business units, products, and locations are included)
Validity dates and surveillance cycle
Certifying body (registrar)
Standard edition (2013 or 2022, as listed on the certificate)
InEvent publicly states ISO 27001 certification in its communications. Treat that as an entry point, then move immediately to evidence: certificate + scope + SoA. (InEvent)
A real ISO 27001 review starts with: “What is in scope of the ISMS?”
If the ISMS scope is narrow (example: “only corporate IT” or “only one product module”), certification does not automatically cover the SaaS platform you are buying.
If the scope is broad (product engineering, operations, support, HR, and the hosting environment), then certification is materially meaningful.
Evidence to request
ISO 27001 certificate (shows scope and dates)
ISMS scope statement (usually a short document)
Statement of Applicability (SoA) (control selection and justification)
Risk assessment methodology and latest risk treatment plan (redacted is fine)
Internal audit schedule and management review summary (redacted is fine)
InEvent also publishes SOC 2 Type II compliance statements and indicates certificates can be requested through account management channels, reinforcing a “provide evidence on request” posture. (InEvent)
The Statement of Applicability (SoA) is the single most useful ISO 27001 document in procurement because it shows how the vendor translated the standard into real controls. A certificate tells you “audited and certified.” The SoA tells you what controls are in scope, which ones are excluded, and why.
How to read the SoA without wasting time
Start with three questions:
Which Annex A controls are marked “not applicable,” and what is the justification?
“Not applicable” can be valid, but weak explanations often hide scope gaps.
Which controls are applicable but implemented through third parties (cloud provider, payment gateway, etc.)?
This is normal in SaaS. You just need the boundary stated clearly.
Which controls rely on process rather than technology?
Training, access reviews, incident response, and vendor due diligence are often process-heavy. You want proof of execution cadence.
What a strong SoA signals
A strong SoA will show:
Clear scope linkage (controls match the actual SaaS service boundary)
Practical control descriptions (not generic boilerplate)
Mapped evidence types (logs, tickets, reviews, policies)
Control ownership (who is accountable internally)
If you only add one requirement to your vendor review checklist, make it this: certificate + scope statement + SoA. That trio prevents most “surprise gaps” later, especially in regulated environments.
ISO 27001 is not a technical checklist. It is a governance standard that forces a company to operationalize:
Risk management (identify, treat, accept, avoid, transfer)
Policy control (documented expectations)
Control implementation (Annex A)
Evidence (audit trails, testing, reviews)
Continuous improvement (nonconformities, corrective actions)
For SaaS event technology, the most decisive control families are typically:
A.9 Access Control
A.10 Cryptography
A.12 Operations Security
A.14 System acquisition, development, and maintenance
A.15 Supplier relationships
A.16 Information security incident management
A.17 Business continuity
A.18 Compliance
Yes. InEvent supports SAML 2.0 and OpenID Connect, including an Azure Active Directory (OIDC) integration path. For governance, enforce mandatory SSO at company or event level and require direct IdP-to-InEvent integration (no intermediary SSO layers). (InEvent FAQ)
Annex A.9 is about ensuring that:
Access is authorized, least-privilege, and reviewed
Users are uniquely identifiable
Privileged access is tightly controlled
Authentication mechanisms are appropriate to risk
Access is revoked quickly when no longer needed
From InEvent’s security data and privacy statements, key access-control measures include:
Role-based access control (RBAC) options for provisioning access (InEvent)
Unique account/username/password access control (InEvent)
Account lockout and password expiration (InEvent)
One-way encryption for all passwords (InEvent)
Logging and auditing for read and write operations (InEvent)
Failed login attempts and malicious input monitoring (InEvent)
Limited IP ranges to user-level access (network-level restriction concept) (InEvent)
Employee access limited to a limited amount of accounts (InEvent)
Physical token access to authenticate operations (an internal operational safeguard) (InEvent)
These statements map directly to common vendor questionnaire prompts: RBAC, authentication, brute-force controls, privileged access restrictions, and audit logging.
InEvent’s SSO guidance states:
Supported methods include SAML 2.0, Azure AD (OIDC), and OpenID Connect (InEvent FAQ)
SSO can be set at company or event level, and applies across both (InEvent FAQ)
InEvent cautions against “intermediary SSO layers” and requires direct IdP integration with InEvent endpoints (InEvent FAQ)
What a government or enterprise buyer should do
Require SSO for staff and admins
Disable local passwords for privileged roles where possible, or restrict to break-glass accounts
Require IdP policies: MFA, device posture, conditional access, geo/IP conditions
Use group-to-role mapping for least privilege
Implement joiner/mover/leaver processes enforced by the IdP, not by manual app administration
Ask for artifacts that prove enforcement and review:
RBAC role matrix (platform roles and what each can access)
SSO configuration guide and supported claims
Audit-log sample exports showing authentication events and administrative actions (InEvent)
Access review process (frequency, approvers, evidence format)
Termination and contractor offboarding procedure (IT + HR handoff)
Yes. InEvent states that data is encrypted and transmitted using Secure Socket Layers (SSL) technology. For enterprise assurance, confirm modern TLS configurations, certificate management, and whether encryption is enforced end-to-end across web, APIs, and integrations. (InEvent)
Annex A.10 ensures cryptography is used correctly:
Protect confidentiality and integrity in transit
Protect confidentiality at rest where required
Control key management (generation, storage, rotation, access)
Define crypto policy (approved algorithms, minimum key sizes, deprecation rules)
InEvent explicitly states encryption in transit via SSL and one-way encryption for passwords. (InEvent)
Practical reading
“SSL” is typically used colloquially to mean SSL/TLS for HTTPS transport encryption.
“One-way encryption for passwords” indicates password hashes rather than reversible encryption.
Even if a vendor states transport encryption, a serious assessment confirms:
TLS versions supported and minimum enforced
HSTS, secure cookie flags, session timeouts
API endpoints enforce HTTPS and reject downgrade
Certificate rotation and key custody controls
Whether administrative interfaces are segregated or protected via additional controls
Evidence to request
Encryption policy excerpt (transport, secrets, password storage)
Key management overview (where keys live, who can access, rotation approach)
Pen test executive summary that includes transport and authentication findings (see Section 4) (InEvent)
Where InEvent does not publish a specific algorithm statement on its public pages, you treat algorithm-level and key-management detail as NDA material in the vendor trust pack, not as assumptions.
Operations security is where SaaS vendors either become predictable or become risky. Annex A.12 focuses on:
Change management
Malware protection and monitoring
Logging and monitoring
Vulnerability management and patching
Backup and recovery
Capacity and availability management
Logging and monitoring
Logging and auditing for read/write operations (InEvent)
Failed login attempts and malicious input monitoring (InEvent)
Vulnerability management remediation timelines
InEvent publishes remediation targets by severity:
Critical: 1 hour
High: 24 hours
Medium: 5 working days
Low: 30 working days (InEvent)
Penetration testing cadence
InEvent states it provides “the latest copy of our quarterly pentest” through project management channels. (InEvent)
Availability and failover posture. InEvent states:
99.9% guaranteed uptime SLA (InEvent)
A failover mechanism triggered when the main server is not responding, with a serverless approach to data backups/accessibility across instances (InEvent)
RTO 4 hours and RPO 24 hours (InEvent)
These are unusually concrete for a public trust page and map directly to business continuity and operations security controls.
Remediation timelines
The severity-based remediation SLAs are strong only if they are backed by:
vulnerability intake process (scanner + triage)
patch/change process
exception handling with risk acceptance
Quarterly pen tests
“Quarterly” is meaningful if the scope is defined:
production application and APIs
authentication paths (including SSO)
OWASP Top 10 testing and business logic testing
follow-up validation of remediations
RTO/RPO
RTO 4 hours and RPO 24 hours indicate a disaster recovery posture where data loss tolerance is up to 24 hours in worst-case scenarios, and service restoration target is within 4 hours. (InEvent)
Your procurement requirement determines whether that is acceptable. Some agencies require tighter RPO for mission systems.
Request operational evidence that matches the published commitments:
Latest pen test executive summary and remediation status (under NDA) (InEvent)
Vulnerability management policy and sample tickets showing SLAs being met (InEvent)
Change management policy and deployment controls
Logging/auditing sample exports for administrative actions and data exports (InEvent)
Annex A.14 is where ISO 27001 becomes real for SaaS buyers, because it covers how security is engineered into the product lifecycle, not bolted on after launch. Most event platforms fail reviews here for one reason: they cannot clearly show how code moves from “developer laptop” to “production” with predictable controls.
In procurement terms, you are looking for evidence that the vendor’s engineering system reduces the two risks that matter most in event software: unauthorized change and unsafe change.
What A.14 is trying to enforce
A.14 is about building and maintaining secure systems through:
Secure design and requirements (security considered before features ship)
Secure development practices (review, testing, scanning)
Controlled environments (dev/test/prod separation)
Controlled releases (approvals, rollbacks, versioning)
Protection of sensitive data in non-production environments
What to validate during an assessment
Even when a vendor does not publish full SDLC details publicly, your review should request a standard “secure SDLC evidence pack” under NDA and validate:
Code review policy: required peer review for production changes, with evidence of review in the ticketing or PR system
Secrets handling: no credentials stored in source control, use of managed secrets, and rotation process
Dependency and vulnerability scanning: how third-party libraries are scanned and how fixes are prioritized (tie back to the remediation SLAs already published)
Release governance: who approves deployments, how emergency fixes are handled, and how rollbacks work
Environment separation: production access restricted, with auditability for administrative actions
Change logging: a clear record of what changed, when, and by whom, aligned to the platform’s logging and auditing posture
Why this matters specifically for events
Events compress risk into short windows. A last-minute agenda change, registration rule update, or integration tweak can create real security impact if deployment is chaotic. A controlled SDLC and release process reduces the “silent failure” mode: a change that breaks login, exposes data through misconfiguration, or disrupts uptime during a live program.
Evidence to request (A.14)
Ask for:
Secure SDLC policy (or security engineering standards)
Change management policy + sample change tickets
CI/CD overview (high level) and release approval controls
AppSec scanning summary (what tools/classes of tests exist)
Exception process (how risk is accepted when timelines are tight)
Annex A.15 is about the reality that SaaS risk is supply-chain risk:
hosting provider controls
email/SMS providers
payment providers
analytics and tracking tools
support tooling
The control requirement is not “we use AWS.” It is:
vendor due diligence
contractual controls
ongoing monitoring and review
clarity on sub-processor roles
Hosting
InEvent states it is hosted on Amazon Web Services (AWS). (InEvent)
Data location
InEvent states servers are located in Virginia (USA) and Dublin (Ireland). (InEvent)
It also states customers can opt into the Ireland-located server for EU privacy alignment. (InEvent)
Sub-processor contracting for GDPR
InEvent states it follows Data Processing Agreements (DPA) and Standard Contractual Clauses (SCC) with sub-processors, and that its DPA is reviewed yearly. (InEvent)
Payments
InEvent states PCI DSS alignment through integrations with gateway providers such as Stripe and PayPal, and that it only uses PCI DSS-compliant gateway providers. (InEvent)
For government and regulated enterprises, you want:
Sub-processor list with purpose and data categories
Evidence of vendor security reviews (SOC reports, ISO certs, SIG/CAIQ)
Data flow diagrams for attendee PII
Contractual controls:
breach notification terms
data deletion/return
access controls
subcontractor change notification
Evidence to request
Current sub-processor list and DPA template (InEvent)
SCCs (where cross-border transfers exist) (InEvent)
Payment flow architecture (whether card data is handled directly or tokenized via gateway) (InEvent)
A.16 requires defined and tested incident handling:
detection and reporting
triage and classification
containment, eradication, recovery
evidence preservation and forensic readiness
stakeholder notification
lessons learned and corrective action
On its GDPR compliance page, InEvent cites the GDPR breach notification requirement “where feasible, within 72 hours,” and states it monitors API usage and provides triggers that can be activated for IT security teams. (InEvent)
This is not a full incident response plan, but it supports:
awareness of regulatory timelines
an operational monitoring concept tied to customer usage patterns
If you want a CISO to approve without a call, provide:
Incident Response Policy (IRP)
Severity classification matrix
On-call coverage model (SIRT)
Evidence retention and log integrity controls
Customer notification workflow and templated communications
Post-incident review process and corrective action tracking
Evidence to request
IRP excerpt and notification SLAs
Last tabletop exercise summary (redacted)
Sample incident postmortem structure (template)
Yes. InEvent publishes a 99.9% uptime SLA, with stated recovery objectives of RTO 4 hours and RPO 24 hours. It also describes an automatic failover mechanism and a backup/accessibility approach across instances for continuity. (InEvent)
A.17 ensures information security continuity is built into business continuity:
continuity planning and testing
redundancy and recovery capability
recovery objectives (RTO/RPO)
communication plans and customer obligations
BCP summary commitments. InEvent publishes a Business Continuity Plan summary, stating it will:
safeguard employees and property
assess financial/operational impact
quickly recover and resume operations
protect books and records
allow clients to use systems
if unable to continue business, assure prompt client access to data and logs (InEvent)
Annual review
InEvent states it updates the plan at least annually and when material changes occur. (InEvent)
Operational targets
From the trust page:
99.9% guaranteed uptime SLA (InEvent)
RTO 4 hours, RPO 24 hours (InEvent)
failover mechanism and backup/accessibility approach across instances (InEvent)
If you are writing contract requirements or a security addendum, align:
SLA and service credits (if applicable)
RTO/RPO commitments for the service tier you are buying
DR test frequency and evidence delivery
Customer obligations (example: IdP uptime for SSO, DNS control for custom domains)
Evidence to request
DR architecture summary and last DR test results (redacted)
BCP full plan under NDA (beyond the public summary) (InEvent)
Incident communications and escalation tree aligned to your agency requirements
Use this as a procurement control map. It is designed to generate a complete evidence request in one pass.
Request: Information security policy, acceptable use, data classification policy
Look for: executive approval, review cadence, training acknowledgement
Request: security governance chart, roles and responsibilities, risk committee outputs
Look for: formal ownership and segregation of duties
Request: background check policy (where applicable), onboarding/offboarding SOP, security training cadence
Request: asset inventory approach for production systems, data inventory for PII
Request: RBAC model, privileged access controls, SSO guide, audit-log samples (InEvent FAQ)
Request: encryption policy, password storage method, key management overview (InEvent)
Request: data center assurance package (inherited from cloud provider), and internal office controls if relevant (InEvent)
Request: vulnerability management policy, remediation SLA evidence, change management, monitoring/logging controls, pen test outputs (InEvent)
Request: network segmentation overview, secure admin access methods, IP restriction approach (InEvent)
Request: secure SDLC policy, code review requirements, OWASP alignment, release controls (InEvent)
Request: sub-processor list, DPA/SCCs, vendor review procedure, payment provider scope (InEvent)
Request: IR plan, notification SLAs, tabletop results, evidence preservation and logging (InEvent)
Request: DR architecture, DR test evidence, BCP full plan, SLA/RTO/RPO commitments (InEvent)
If you want a reviewer to close the assessment fast, bundle these in a trust pack (with NDA where needed):
ISO 27001 certificate + scope + SoA (confirm standard edition and registrar) (InEvent)
SOC 2 Type II report (latest period) (InEvent)
Quarterly pen test executive summary + remediation status (InEvent)
Vulnerability management SLAs and evidence of adherence (InEvent)
Trust metrics: SLA, RTO/RPO, failover description (InEvent)
DPA + SCCs + sub-processor list (and data residency options) (InEvent)
Yes. InEvent states it is SOC 2 Type 2 certified/compliant and indicates a copy of the certificate can be requested through account management channels. (InEvent)
Yes. InEvent states its servers are located in Virginia (USA) and Dublin (Ireland), and customers can opt into the Ireland server location for EU privacy alignment. (InEvent)
Yes. InEvent states that data is encrypted and transmitted using SSL technology. Validate TLS configuration, certificate lifecycle, and enforcement across APIs during the security review. (InEvent)
Yes. InEvent states that logging and auditing are available for read and write operations and that it monitors failed login attempts and malicious input. Validate by requesting sample exports aligned to your use cases (exports, admin actions, SSO logins). (InEvent)
Yes. InEvent publishes a 99.9% uptime SLA, describes a failover mechanism, and provides RTO 4 hours and RPO 24 hours targets. Confirm whether your service tier and contract incorporate these targets and what evidence is available for DR testing. (InEvent)
Yes. InEvent states that a copy of its quarterly pen test can be provided through project management channels. Request an executive summary plus remediation status, under NDA, and ensure scope includes the production web app and APIs. (InEvent)
Yes. InEvent publishes remediation targets by severity: Critical 1 hour, High 24 hours, Medium 5 working days, Low 30 working days. Validate with evidence from ticketing and change management and ask how severity is assigned and governed. (InEvent)
