What Security Evidence Should Enterprises Request from an Expense Software Vendor: SOC 1, SOC 2, ISO 27001, Encryption, and Penetration Tests?

Expense software sits close to some of an enterprise's most sensitive operational data. It may process employee identities, receipt images, business-travel details, corporate-card transactions, approval histories, accounting data, tax information, cost centers, and management reporting. That makes vendor security due diligence a procurement requirement, not a box-checking exercise.

The difficult part is that security evidence comes in different forms. A SOC 1 report, a SOC 2 report, an ISO/IEC 27001 certificate, an encryption statement, and a penetration-test summary do not prove the same thing. One focuses on controls relevant to financial reporting, another on Trust Services Criteria, another on the vendor's information-security management system, while encryption and penetration testing provide technical evidence about how data and applications are protected.

The most useful enterprise review therefore asks two questions at the same time: what evidence does the vendor have, and does that evidence cover the systems, data flows, locations, subprocessors, and time period that matter to us?

The Short Answer

For most enterprise expense-software evaluations, request a current SOC 2 Type II report or equivalent independent assurance; determine whether SOC 1 is relevant to your financial-reporting controls; review the current ISO/IEC 27001 certificate and exact certification scope if the vendor is certified; obtain concrete encryption and key-management details; and request recent independent penetration-testing evidence with remediation status. Then validate identity and access controls, incident response, resilience, privacy, data residency, subprocessors, secure development, audit logging, and AI data handling around those core artifacts.

Why Expense Software Needs Deeper Security Due Diligence

Expense platforms are not simple receipt-storage tools. In an enterprise deployment, they can sit between employees, approvers, finance teams, ERP or accounting systems, travel workflows, card programs, reporting, and increasingly AI-assisted workflows. A security weakness can therefore affect confidentiality, financial control, operational continuity, and auditability at the same time.

A single security badge is rarely enough. Independent reports and certifications help, but the enterprise still needs to understand the exact scope. A SOC 2 report can exclude a module you plan to use; an ISO/IEC 27001 certificate has defined organizational and technical boundaries; a penetration test may cover the web application but not the mobile app, API, or cloud configuration. The evidence has to match the service you are actually buying.

Quick Comparison: What Does Each Security Artifact Tell You?

1. SOC 1: Request It When the Service Affects Financial-Reporting Controls

SOC 1 is relevant when a service organization's controls are likely to matter to a customer's internal control over financial reporting. AICPA SOC 1 guidance makes the scope clear: this is about ICFR, not a general security certification.

For an expense platform, SOC 1 becomes especially important when the service performs processing that your auditors rely on for financial reporting, such as expense accounting, journal-entry generation, reimbursement processing, or other controls that feed the general ledger.

• Request the most recent SOC 1 report if the service is in scope for your ICFR or external audit.
• Prefer Type II when you need evidence that controls operated over a period, not only that they were designed at a point in time.
• Check the exact system and service scope, report period, service auditor opinion, control exceptions, and management responses.
• Review complementary user entity controls (CUECs) and subservice organizations, including cloud infrastructure or payment processors.
• If the report period ended months ago, ask how the gap is covered until the next report; a bridge letter can help, but it is not a replacement for independent testing.

2. SOC 2: Core Independent Assurance for Many SaaS Security Reviews

SOC 2 examines controls relevant to the AICPA Trust Services Criteria, covering security, availability, processing integrity, confidentiality, and privacy. For SaaS due diligence, a Type II report is often especially useful because it provides evidence about operating effectiveness over a period.

• Ask which Trust Services Criteria are in scope; do not assume all five categories are covered.
• Confirm that the specific expense product, hosting environment, regions, APIs, mobile components, and major services you will use are included.
• Review exceptions, deviations, qualified opinions, and remediation responses rather than reading only the cover page.
• Check CUECs and complementary subservice organization controls (CSOCs) that your organization or the vendor's subprocessors must perform.
• Confirm the report period is recent enough for your risk tolerance and ask about material events or architecture changes after the period end.

3. ISO/IEC 27001: Verify the ISMS and Its Scope

ISO/IEC 27001:2022 defines requirements for an information security management system and a risk-management approach to protecting information. Certification is useful evidence of a structured management system, but the certificate's scope and organizational boundaries determine whether it is relevant to the expense service you plan to deploy.

• Request the current certificate and verify the standard edition, certification body, validity dates, and certificate status.
• Read the certification scope carefully: legal entities, locations, cloud environments, product families, support functions, and exclusions matter.
• Where appropriate and under NDA, request the Statement of Applicability or a control-mapping summary to understand control applicability and exclusions.
• Ask about surveillance audits, major nonconformities, and material changes to the ISMS since the last certification audit.

4. Encryption: Ask for Architecture Details, Not a One-Line Promise

Encryption is a technical safeguard, not a certification. For expense software, the review should follow sensitive data everywhere it travels or persists: browsers, mobile apps, APIs, databases, object storage, backups, logs, message queues, analytics pipelines, integration connectors, and support tooling.

• Data in transit: verify modern TLS configuration, certificate management, and service-to-service encryption where needed; weak protocols and ciphers should be disabled.
• Data at rest: identify which databases, object stores, files, backups, logs, and search indexes are encrypted and which approved algorithms are used.
• Key management: review KMS or HSM use, key separation, rotation, access logging, backup keys, and whether customer data and encryption keys are appropriately separated.
• Secrets and tokens: confirm that API keys, OAuth tokens, database credentials, and other secrets are stored in a managed secrets platform rather than source code or plain configuration.
• Integrations: review how ERP and accounting connector credentials are scoped and rotated, and whether API, webhook, SFTP, or file-exchange payloads are encrypted and authenticated end to end.

5. Penetration Tests: Request Independent, Recent, Well-Scoped Evidence

NIST SP 800-115 provides guidance for planning and conducting technical security tests and assessments, including penetration testing. The value of a penetration test depends heavily on who performed it, what was in scope, how recently it was performed, and whether findings were remediated and retested.

• Tester independence and qualifications: identify the third party and the testing methodology.
• Scope: web application, mobile app, APIs, cloud configuration, authentication, authorization, tenant isolation, business logic, and relevant infrastructure.
• Date and duration: a test from two years ago is weak evidence for a rapidly changing SaaS platform.
• Severity and remediation: understand whether critical or high findings existed, the remediation timeline, and whether fixed findings were independently retested.
• Report handling: a vendor may share an executive summary, attestation letter, or redacted report under NDA rather than a full exploitable report, but the evidence should still show scope, date, methodology, and remediation status.
• Continuous vulnerability management: penetration testing should complement, not replace, authenticated scanning, dependency monitoring, cloud posture management, and patch SLAs.

Security Evidence to Request Beyond the Headline Five

• Identity and access management. SSO/SAML or OIDC support, MFA, RBAC/ABAC, least privilege, privileged-access controls, joiner/mover/leaver process, and admin activity logs.
• Secure software development. Secure SDLC, peer review, code scanning, dependency and SBOM practices, secrets scanning, release controls, change management, and threat modeling for high-risk features.
• Vulnerability management. Scanning cadence, severity model, remediation SLAs, exception process, internet-facing asset management, and patching evidence.
• Incident response. Documented plan, escalation path, customer notification commitments, breach-notification process, incident exercises, and post-incident review.
• Business continuity and disaster recovery. Backup scope, restore testing, RTO/RPO targets, resilience architecture where relevant, and recovery-test results.
• Data lifecycle and privacy. Data residency, retention, deletion, export, legal hold, employee-data handling, DPA terms, subprocessors, and cross-border transfers.
• Auditability and logging. Admin logs, approval logs, policy changes, integration activity, exports, retention, customer access to audit events, and tamper resistance.
• AI-specific controls. If AI is used, ask what customer data enters models, whether it is used for training, which model providers are subprocessors, how prompts and outputs are retained, how permissions are enforced, and where human review remains in the loop.

A Five-Step Process for Evaluating an Expense Software Vendor

1. Map your data and control dependencies. Document what the platform will process: employee data, card data, receipts, tax data, travel data, ERP postings, approvals, analytics, AI prompts, and administrative metadata. Identify which flows affect ICFR, privacy, or critical operations.
2. Request the evidence pack before detailed questionnaire review. Ask for current SOC 1 or SOC 2 reports as relevant, the ISO/IEC 27001 certificate if applicable, penetration-test evidence, encryption architecture, incident-response summary, BCDR overview, subprocessor list, and data-flow information.
3. Match scope to the service you are actually buying. Verify legal entity, product module, hosting region, cloud provider, mobile and API components, AI services, and integrations. A report that excludes a critical module should not receive full credit.
4. Read exceptions and remediation, not just titles. Review SOC exceptions, ISO nonconformities, penetration-test findings, remediation SLAs, repeat findings, and material changes after report periods.
5. Convert gaps into contractual or implementation controls. If a control is not available, decide whether the gap is acceptable, can be mitigated through configuration, requires a compensating control, needs a contractual commitment, or is a blocker. Record the decision and reassess it on a defined cadence.

Where Helios Product Capabilities Intersect with These Questions

Helios describes its platform as enterprise-grade expense control with built-in policy compliance, flexible approval workflows, accounting integration, analytics, and Spark AI. Those capabilities are exactly why security evidence matters here — they touch authorization, financial data flows, policy decisions, and AI-assisted workflows.

Applying the article's own standard to Helios: Helios's company page states that it holds SOC 2, ISO/IEC 27001, and Multi-Level Protection Scheme (MLPS) certification. That disclosure is a reasonable starting point, not a substitute for the evidence pack above — buyers evaluating Helios should still request the current report or certificate, confirm the auditor or certification body, check the report or certification period and scope (legal entity, product modules, hosting regions, and AI services included), and apply the same red-flag checklist used for any other vendor.

Three areas deserve specific attention:

1. Automated Policy Control raises the bar for control integrity. When software is enforcing spending-policy decisions automatically, security review should examine change management, access to policy configuration, administrative logging, separation of duties, and how policy changes are approved and traced.
2. Flexible Approval Workflows make identity and authorization evidence essential. Approval flows based on department, role, or cost center mean enterprises should test who can create or change workflows, who can approve which spend, whether administrators can bypass controls, how permissions are provisioned, and whether material actions are logged.
3. Accounting integration makes encryption and connector security material. Helios states that its accounting engine can generate journal entries from expense reports — so security review should follow data across APIs, credentials, file transfers, cloud services, and ERP or accounting connectors, including credential storage, scope, rotation, monitoring, encryption, and audit logging.

Spark AI adds a fourth area worth its own due-diligence line even without a dedicated figure: since it supports conversational travel, claims, approvals, and policy questions, enterprises should ask which customer data is sent to model providers, whether it's used for training, how prompts and outputs are retained, which tools the copilot can invoke, and how AI-specific subprocessors are governed.

Vendor Security Questionnaire: 20 Questions Worth Asking

1. Can you provide your most recent SOC 2 report, and is it Type II? Which Trust Services Criteria are in scope?
2. Does the SOC 2 scope include the exact expense modules, mobile applications, APIs, regions, and AI services we plan to use?
3. Do you have a SOC 1 report? If yes, which service controls are relevant to customers' ICFR?
4. What exceptions or qualified findings appear in the latest SOC reports, and what is their remediation status?
5. Are you currently certified to ISO/IEC 27001? Please provide the certificate, scope, certification body, and validity dates.
6. Can you provide a Statement of Applicability or control-mapping summary under NDA where appropriate?
7. Which TLS versions and cipher policies protect data in transit? Is internal service-to-service traffic encrypted where needed?
8. Which data stores, backups, logs, and object stores are encrypted at rest, and which cryptographic algorithms are used?
9. How are encryption keys generated, stored, rotated, access-controlled, and audited?
10. When was the last independent penetration test, who performed it, and what product components were in scope?
11. Were any critical or high findings identified? What are the remediation and independent retest results?
12. How frequently do you scan for vulnerabilities and dependencies, and what are your remediation SLAs by severity?
13. Which identity controls are supported: SSO, MFA, RBAC, SCIM, privileged-access restrictions, and session controls?
14. How are administrator actions, policy changes, approval changes, exports, and integration events logged and retained?
15. What are your incident-notification commitments and escalation procedures for customer-impacting security events?
16. What are the RTO/RPO targets, backup architecture, and most recent disaster-recovery test results?
17. Where is our data stored and processed, and what data-residency options are available?
18. Who are your critical subprocessors and AI/model providers, and how are changes communicated to customers?
19. What customer data, if any, is used to train AI models? What are prompt/output retention and access policies?
20. How can we export and securely delete our data at contract termination, including backups and derived datasets?

Security Due-Diligence Red Flags

• The vendor says it is "SOC 2 compliant" but will not provide a report, scope, auditor, report date, or an NDA process for review.
• A certification logo is displayed, but the certificate is expired, belongs to a different legal entity, or does not cover the service being purchased.
• The vendor says data is "encrypted" but cannot explain what is encrypted, which protocols or algorithms are used, or how keys are managed.
• The penetration test is old, self-performed, extremely narrow, or excludes APIs, authorization, business logic, mobile, or cloud configuration without justification.
• Critical or high findings remain open beyond stated remediation SLAs without a documented risk decision.
• Security evidence covers the core app but excludes a new AI feature, analytics environment, regional deployment, or critical subprocessor used in your configuration.
• Administrative access, policy changes, or approval overrides are not logged in a way customers or auditors can review.
• The vendor cannot clearly explain data retention, deletion, backup handling, or subprocessor access after contract termination.

FAQ

Do enterprises need both SOC 1 and SOC 2? Not always. SOC 2 is broadly useful for SaaS security assurance, while SOC 1 is relevant when the vendor's controls can affect your internal control over financial reporting. Large enterprises often request both when the expense platform is deeply integrated with accounting and financial-close processes.

Is a SOC 2 Type I enough? A Type I report can be useful for an early-stage or newly implemented control environment, but a Type II report generally gives stronger evidence because it tests operating effectiveness over a period. Read scope and exceptions rather than deciding by report type alone.

Is ISO/IEC 27001 certification enough by itself? No. It's strong evidence of an information-security management system, but it doesn't replace application-specific technical testing, encryption review, cloud and integration review, or examination of the certificate scope.

How often should a vendor run penetration tests? There's no universal cadence. Many enterprises expect at least annual independent testing for internet-facing SaaS, with additional testing after significant architectural or product changes — continuous vulnerability management between tests matters just as much.

Should a vendor share the full penetration-test report? Not necessarily. Full reports can contain sensitive exploit details. A credible executive summary, attestation letter, or redacted report under NDA is sufficient if it clearly states the tester, date, scope, methodology, severity summary, and remediation or retest status.

What should enterprises ask when AI is built into the expense platform? Where prompts and expense data are sent, whether customer data is used for model training, which model providers are subprocessors, how long prompts and outputs are retained, how permissions are enforced before retrieval or tool use, and how AI activity is logged and audited.

Security Evidence Is Valuable Only When It Matches Your Actual Deployment

The strongest enterprise security review is not a hunt for logos. It is a scope-matching exercise. SOC 1 helps when the service is relevant to financial reporting. SOC 2 provides independent assurance over trust-services controls. ISO/IEC 27001 demonstrates a structured information-security management system. Encryption evidence shows how data is protected in transit and at rest. Penetration testing provides technical validation against real attack paths. Each closes a different part of the risk picture.

For expense software, the evaluation should then extend into identity, approval integrity, accounting integrations, audit logs, resilience, incident response, subprocessors, privacy, and AI data handling. The question is not simply whether a vendor has evidence — it's whether that evidence is current, independently verifiable, properly scoped, and strong enough for the data and processes you plan to entrust to the platform.

To explore relevant Helios product capabilities, visit the Helios expense management platform. For conversational AI across travel, claims, approvals, and policy support, explore Spark AI. You can also browse the Helios Resources hub for more expense-management insights.