Security

Our approach to protecting the PayConnect platform and your data.

Security is central to how PayConnect designs and delivers its financial close automation, SAP cash application, and reconciliation platform (the "Software"). This page explains our approach to protecting the Software and the data it processes, and clarifies how responsibilities are shared between PayConnect and the organizations that use our Software ("Customers").

1. Our Approach to Security

We build security into the Software through secure development practices, access controls, and encryption, and we work closely with each Customer's IT and security teams during implementation to align the Software with their existing security policies and controls.

2. Deployment Model and Data Residency

Unlike a typical multi-tenant cloud SaaS product, PayConnect is deployed within Customer's own network infrastructure. This means Customer's financial, transactional, and SAP or ERP data is processed and stored within Customer's own environment, under Customer's own infrastructure and network controls, rather than in infrastructure operated by PayConnect. This deployment model gives Customer direct control over where its data resides and who can access the underlying servers, storage, and network.

3. Encryption

All communication with and within the Software is protected using industry-standard TLS/SSL encryption, so data moving between application components, integrations, and user sessions is encrypted in transit. Because the Software runs within Customer's own infrastructure, encryption of data at rest is implemented through Customer's underlying storage and infrastructure security controls; PayConnect designs the Software to operate within and support encrypted storage environments configured by Customer's IT team.

4. Secure Software Development

We follow a secure software development lifecycle that includes code review, dependency and library management, and testing prior to release. Updates and patches are made available to Customers on an ongoing basis to address functional issues and security concerns as they are identified.

5. Access Controls and Authentication

The Software includes role-based access controls that allow Customer to define which Authorized Users can access specific features and data within the application. Customer is responsible for provisioning and de-provisioning Authorized User accounts, enforcing strong authentication practices, and promptly removing access for users who no longer require it.

6. Vulnerability Management and Patching

We monitor for security issues affecting the Software and its dependencies and provide patches and updates to Customer to address identified vulnerabilities. We encourage Customers to apply provided updates promptly and to maintain their own vulnerability management practices for the underlying infrastructure and network on which the Software is deployed.

7. Shared Responsibility Model

Because the Software is deployed within Customer's own network, security is a shared responsibility:

AreaPayConnect's ResponsibilityCustomer's Responsibility
Application securitySecure development, application-level access controls, TLS/SSL encryption in transit, patches and updatesApplying provided updates and configuring role-based access appropriately
Infrastructure and networkGuidance on recommended configurationsPhysical security, network security, firewalls, server hardening, and infrastructure monitoring
Data at restDesigning the Software to support encrypted storageConfiguring and maintaining storage encryption and backups within its own environment
User access managementProviding role-based access featuresProvisioning, reviewing, and revoking Authorized User accounts and credentials

8. Incident Response

If PayConnect becomes aware of a security issue affecting the Software, we will notify affected Customers without undue delay and work with Customer's IT and security teams to investigate and remediate the issue. Because the Software operates within Customer's own network, Customer's internal incident response team is typically the first line of response for issues arising from Customer's own infrastructure, and we coordinate with that team as needed.

9. Reporting a Security Vulnerability

If you believe you have discovered a security vulnerability in the Software, please report it to us via our Contact page so we can investigate promptly. Please provide enough detail for us to reproduce the issue and avoid accessing or modifying data beyond what is necessary to demonstrate the vulnerability.

10. Changes to This Policy

We may update this Security page from time to time to reflect changes in our practices. We will post the updated page with a revised effective date.

11. Contact Us

If you have questions about our security practices, please reach out via our Contact page.