Privacy Policy

NC SYNOD, ELCA
DATE: 06/26/2025
VERSION: 01

Introduction

This document defines the NC Synod’s security policy on the processing of card payments via website (Ecommerce, card-not-present), face to face and MOTO (mail order/telephone order) payment channels and handling of associated payment card data.

This security policy shall be reviewed annually and updated as needed and whenever the environment changes, to ensure policy statements remain appropriate for the protection of payment card data.

Scope

This policy applies to:

• All card-not-present Ecommerce payments processed via the hosted web interface (hosted payment page).
• All face-to-face card payments processed via the virtual terminal payment solution
• All MOTO payment card transactions, such as where cardholder data is received on paper (e.g. pew cards) or over the telephone, manually entered into the virtual payment terminal solution
• All those parties with responsibility for taking card payments for Face to Face and MOTO transactions.This includes and is not limited to the NC Synod’s staff, temporary or contractors and volunteers accepting card payments or handling payment card data.
• All those parties with responsibility for managing and maintaining NC Synod’s websites who must ensure that applicable policy requirements are implemented to help protect the websites from compromise and maintain the integrity of the redirection mechanism that links cardholders to the hosted web interface
• Managers/supervisors who must ensure that:
  • Supporting security policies and operational procedures, as appropriate to support adherence to and implementation of this security policy, are documented and kept up to date.
  • This security policy, including any supporting security policies and operational procedures, are in use and known to all affected staff.
  • Those staff/volunteers processing card details understand their responsibilities and meet the requirements set out in this document.

Optionally, for churches that offer their church members and donors the ability to pay using Vanco Give+ Text or Give+ Mobile, this policy also applies to:

• All card-not-present (mobile) payments processed via the Vanco supplied and managed Give+ Text or Give+ Mobile

Definitions

• Cardholder data - includes the primary account number (PAN, the long card number shown on the payment card), cardholder name and expiry date.
• Sensitive authentication data - includes the full track data (magnetic stripe data or equivalent on the chip), card verification code or value (the three-digit or four-digit number printed on the card) and the PIN/PIN block.
• Payment card – defined by the PCI Security Standards Council[1] as any payment card bearing the logo of one of the PCI SSC’s founding members: American Express, Discover, JCB, MasterCard or Visa.
• Payment card data (also referred to as Account Data) – the cardholder data and sensitive authentication data shown on the card or stored in the magnetic stripe/chip.
• Service provider - Any third-party organization which processes payment card data on behalf of the NC Synod, that payment card data is shared with or that could impact the security of payment card data. For example, a document-retention company that stores paper documents that include payment card data.
• SAQ - Self-Assessment Questionnaire – the NC Synod will self-assess and attest to compliance with the PCI DSS.
• Firewall (also known as Network Security Controls (NSC)) - Hardware and/or software technology that protects network resources from unauthorized access. A firewall permits or denies computer traffic between networks with different security levels based upon a set of rules and other criteria.
• Systems – in the context of this information security policy ‘systems’ refers to:
  • The computer system(s) used to access the virtual payment terminal for the submission of card payments, including the network devices that support their network connectivity; and,
  • Any church web server that includes an Ecommerce redirection mechanism used to redirect the cardholder to a hosted web interface (hosted payment page) for submission of card payments
• Administrator –in the context of this information security policy ‘administrator’ refers to IT systems administrators, the internal or external personnel responsible for configuring, managing and maintaining computer systems, firewalls, network devices, web servers, etc.

Policy Statements

Approved payment methods

All payment methods for the processing of payment card transactions must first be approved. Approval is provided by Evin Burleson, director of finance and administration. Evin will maintain the list of approved payment methods.

The current credit card processing solution for the Church is provided by ACS Technologies. No other methods of card processing are permitted without prior approval of synod leadership.

Website Ecommerce payments:

• Card payment submission and processing shall be via a hosted web interface (hosted payment page) accessed by the cardholder using an internet connected web browser
• All account data functions must be entirely outsourced to PCI DSS validated third-party service providers
• All elements of the hosted payment page delivered to the cardholder’s browser must originate only and directly from a PCI DSS validated third-party service provider
• The NC Synod will not electronically store, process, or transmit any payment card data relating to Ecommerce payments on its own systems or premises, but will rely entirely on the third parties named above to handle all these functions
• Specifically, for online Ecommerce payments all processing and handling must satisfy the requirements set out in the SAQ A[2]

Face-to-face and MOTO payments:

• Card payment submission and processing shall be via a hosted web interface (virtual payment terminal) accessed by the NC Synod from an internet connected web browser
• The virtual payment terminal solution (Access ACS, Realm, Abundant) shall be provided and hosted by a PCI DSS validated third-party service provider
• The NC Synod’s computer system or device used to access the virtual payment terminal must be in an isolated single location and not connected to any other systems within the church or associated buildings, must not have any software which might enable card details to be stored electronically, and must not have any hardware devices attached i.e. card readers
• The NC Synod will not electronically transmit card payments through other channels via the internal network
• The NC Synod will not store payment card data electronically
• Specifically, all processing and handling must satisfy the requirements set out in the SAQ C-VT[3]

Optionally, churches may also offer their church members and donors the ability to pay using Vanco Give+ Text or Give+ Mobile.

Mobile payments:

• Card registration, payment submission and processing shall be via a hosted mobile web interface (hosted payment page) accessed from the member or donor’s own mobile device
• All account data functions must be entirely outsourced to the PCI DSS validated third-party service provider, Vanco Payment Solutions
• All elements of the hosted mobile card registration and payment page delivered to the cardholder’s mobile device must originate only and directly from a PCI DSS validated third-party service provider
• The NC Synod will not electronically store, process, or transmit any payment card data relating to Mobile payments on its own systems or premises, but will rely entirely on the third party named above to handle all these functions
• Specifically, for Vanco Give+ Text or Give+ Mobile payments all processing and handling must satisfy the requirements set out in the SAQ A[4]

No other receipt or transmission of payment card data via electronic means is permitted.

The approved payment methods used ensure that payment card data is properly encrypted, using industry-standard strong cryptography and security protocols, when it is sent (transmitted) over the Internet.

When submitting payments via the browser-based virtual payment terminal, the person entering the payment must check that 'https' appears in the URL of their browser, indicating a secure connection. If the virtual payment terminal is not showing 'https' then it is not a secured connection and payment card data should not be entered into the virtual terminal web page.

Maintain a Secure Network and Systems

Church systems must be protected by a firewall, which is usually installed between the Internet and the system.

Firewalls must be set up to only allow inbound and outbound connections that are necessary for church operations and processes.  The firewall must only allow the outbound network traffic that has been authorized and is required by the church.

Firewalls must restrict inbound and outbound traffic from computer systems used to access the virtual payment terminal to only that which is necessary for the taking and submission of card payments.  Network traffic that is not specifically needed for this purpose must be denied by the firewall.

If wireless technologies are used by the church, for example to provide a guest Wi-Fi network for churchgoers or to provide network connectivity for church wireless devices, the following policies apply:

• A firewall must be in place to separate the wireless technology from church systems and to control all traffic from the wireless network
• The wireless access point/router’s default (‘out of the box’) settings, including all pre-set passwords must be changed
• The wireless networks must be set up to use strong wireless authentication and encryption. WEP must not be used for encrypting wireless networks.

Security controls must be implemented to protect any computing or mobile devices (including those owned by the church or an individual) that are used to connect to the Internet (or other untrusted networks) when outside the church network and which also are used to access the virtual payment terminal.  Host-based security controls, such as personal firewall software or end-point protection solutions, or network-based controls, such as firewalls, network-based heuristics inspection, or malware simulation, may be used.

The security controls must be configured to a set standard to prevent threats being introduced into the church network by the computing or mobile device after their connection to untrusted networks.  The personal firewall software must run at all times (is 'always on') and users of the computing or mobile device must not be able to change how the security controls are set up.

Configure Systems Securely

Default / factory settings, account names and passwords that come with or are pre-set on systems must be changed or disabled before the systems are installed.  In addition, any unnecessary default accounts, must be removed from systems.

Computer systems used to access the virtual payment terminal must be configured securely or ‘hardened’.

Secure system configuration must include:

• Configuring system security parameters to prevent misuse.
• Enabling only necessary services, protocols, daemons and functions, etc. to minimize the available functions that could be exposed to and potentially exploited by malware or malicious individuals
• An identified business need and justification for enabling any insecure services, protocols or daemons, such as FTP or Telnet
• Implementation of additional security measures or controls to protect systems if any insecure services, protocols or daemons are needed and used.
• Removing unnecessary system functionality and/or features, such as file sharing, remote desktop/remote support access

If firewalls, network devices and/or the computer systems used to access the virtual payment terminal can be administered by personnel that are not physically in front of them (i.e. these systems are connected to across a network), the access method used must encrypt the communication.

A method of strong encryption must be used for all such non-console administrative access; insecure methods must be disabled or removed.

If non-console administrative access is available from outside of the church network, a method of multi-factor authentication must be used.  Multi-factor authentication uses a minimum of two forms of unique authentication to prove a users' identity.

Protect payment card data

Any paper documents showing cardholder data or sensitive authentication data, i.e. donor forms, must be held securely.  This includes physically securing media to prevent it being accessed or viewed by personnel with no church/business need to see payment card data.

Methods to physically secure paper documents may include storing them in a locked drawer, cabinet or safe, or other method that protects the media from unauthorized access, accidental loss or theft.

Only personnel/roles with a legitimate need may be allowed to view displays (on screen or on paper) of more than the BIN (first six to eight digits) and last four digits of the primary account number (long card number). Everyone else must only be able to see a masked card number.

Payment card data must not be retained electronically.

If payment card data is received or shown on paper, the following policy statements then apply:

• The amount of payment card data stored and the duration of its storage must be limited to only that required to satisfy all legal, regulatory and business requirements for data retention.
• If sensitive authentication data is received, immediately after the initial payment transaction has been processed all sensitive authentication data must be securely destroyed, or redacted to obscure or ‘black out’ the data, so that the sensitive authentication data is rendered unrecoverable.
• The NC Synod’s policy is to hold cardholder data on paper for no longer than 90 days.
• Cardholder data must be securely destroyed or redacted to obscure or ‘black out’ the cardholder data, when the retention period is exceeded. There must be a quarterly process for identifying and rendering unrecoverable any cardholder data that exceeds the retention period.

Approved methods of destruction of payment card data include crosscut shredded, incinerated or pulped so that cardholder data cannot be reconstructed.

If payment card data is placed into storage containers prior to destruction, e.g. by a third-party document destruction company, those containers must be secured to prevent access to the contents.

The movement or distribution of any media containing or showing payment card data must be controlled, for example when transferring pew cards from the church to administrative offices:

• Identify and classify any such media (i.e. as ‘confidential’) to ensure appropriate handling by staff, volunteers, etc.
• If any media containing payment card data is sent/moved between church locations, it must always be sent by a secure and tracked method or kept ‘in hand’ by church staff
• If any media containing payment card data is held in offline or backup locations, it must be physically secured to prevent unauthorized access.
• Make sure that there is church management approval for any such movement or distribution of media containing payment card data, i.e. approval of method used, signatory on courier tracking receipt.

Physical access controls must be in place to make sure that unauthorized persons do not have physical access to church systems used to process or transmit cardholder data. This includes physical entry controls that can monitor access and make sure that only authorized personnel can gain physical access to these systems.

Implement Strong Access Control Measures to keep access to a minimum

Access to the computer systems or devices from which the virtual payment terminal is accessed should be restricted to only those individuals who have a legitimate need for access for the purpose of processing card details.

Users of the computer systems or devices from which the virtual payment terminal is accessed must only have the access and privileges to the systems and data that they need to do their job.

Separate administrator and user logins (accounts) must be used, so that administrative rights can be given only to delegated personnel who need the extra level of access and rights to be able to do their job.  For example, firewall or web server administrators.

All systems users/administrators must have their own individual login (unique id) and password.  This includes any users/administrators with access to a church web server that is set-up with an ecommerce redirection mechanism, this is to help protect the website/web server from compromise and maintain the integrity of the redirection mechanism.

Systems must require the selection of strong passwords (or passphrases), which must be of a minimum of twelve alphanumeric characters.  If the system does not support twelve characters, a minimum length of eight characters is permissible.

A unique password must be set for each new account created or user password reset.  The user must be forced to change their password or passphrase the first time they log-in.

Systems must be configured to require that new passwords cannot be the same as any of the four previously used passwords.

Passwords must be changed at least once every 90 days, or the security posture of accounts must be dynamically analyzed, and real-time access to resources automatically determined accordingly.

A token device, smart card or biometric may be used instead of passwords to authenticate systems users and administrators.

Use of generic usernames, accounts or group or shared user ID's (shared accounts), including shared passwords or other shared authentication credentials, is permitted only on an exception basis as follows:

• Use of such accounts shall be prevented unless needed for an exceptional circumstance.
• Use must be time-limited to the period of the exceptional circumstance, supported by written business justification that is explicitly approved by church management.
• Individual user identity must be confirmed before access to such accounts is granted.

Every action taken by any such generic or shared account (or shared authentication credentials) shall be attributable to an individual user.

Access to systems must be removed for personnel on the termination of their relationship with the church, their employment or contract.

Protect Systems against malicious software

Anti-malware solutions (e.g. anti-virus software) must be installed and actively running on any computer system used to access the virtual payment terminal.  Users of the systems must not be able to alter or disable this anti-malware software.

The anti-malware solution used must be capable of detecting, and then removing blocking or containing, all known types of malicious software (malware).

The anti-virus solution must be set to update automatically and to retain audit logs of its activity, for at least one year.

The anti-virus solution must be set to regularly run full system scans, as well as real-time scans. Or be capable of performing continuous behavioral analysis of systems or processes.

To ensure malware cannot be introduced via external removable media, the anti-virus solution must either perform automatic scans, or be capable of performing continuous behavioral analysis, when the media is inserted/connected.

Automated technical mechanisms must be in place to protect against and mitigate the risk posed by phishing attacks against staff.

Protect Systems by keeping them up to date

Operating systems and software on computer systems used to access the virtual payment terminal, websites/webservers, applications and software (including open source or third-party components), supporting operating systems, as well as the supporting network devices and firewalls, must be kept up to date and be supported by the vendor or supplier.

Systems and software must be protected from known vulnerabilities by installing vendor-supplied security patches.

A process must be in place to identify security vulnerabilities that may impact systems used by the church, e.g. by subscribing to industry security sources, vulnerability announcements and/or vendor patch management alerts.

Responsible personnel must be assigned to monitor the release of new security vulnerabilities, and to risk-rank those vulnerabilities to determine the level of risk to church systems, such that action is taken to address those vulnerabilities within a timeline appropriate to the level of risk.

Critical patches (as determined by the risk-ranking process) must be installed within 1 month of release. Critical security updates and patches are those evaluated as being necessary to address an imminent threat to the website/webserver, to address vulnerabilities impacting critical systems, and/or that could result in a potential compromise if not installed.

Manage and Protect Payment Page Scripts

The policy statements in this section apply only to Church website(s) that include either an ACS Technologies’ or a Vanco Payment Solutions' hosted payment page embedded as an inline frame or iFrame:

All payment page scripts that are loaded and executed in the cardholder’s browser must be managed, as follows:

• A method shall be implemented to confirm that each script is authorized.
• A method shall be implemented to ensure the integrity of each script.
• An inventory of all scripts must be maintained, with written business or technical justification as to why each is necessary.

Note: this policy applies to all scripts loaded from the Church’s environment and scripts loaded from third and fourth parties.

Unauthorized changes on payment pages shall be detected and responded to through deployment of a change- and tamper-detection mechanism, as follows:

• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP header and payment page.
• The mechanism functions are performed as follows:
  • At least once every seven days

OR

• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in PCI DSS Requirement 12.3.1).

Regularly test security systems and processes

The policy statements in this section apply to NC Synod web servers that host the page(s) that either 1) redirect cardholders from the church website to ACS Technologies’ or Vanco Payment Solutions for payment processing (for example, with a URL redirect), or 2) include either an ACS Technologies’ or a Vanco Payment Solutions’embedded payment page/form (for example, an inline frame or iFrame).

External vulnerability scans must be performed at least once every 3 months by a PCI Approved Scanning Vendor(ASV).

Vulnerabilities identified by the ASV scan must be resolved and re-scans performed, as needed, until passing scans are achieved. A 'passing' external vulnerability scan must be achieved at least once every 3 months.

External vulnerability scans must be performed after any significant change.  These scans may be performed by a suitably qualified internal person(s) or external organization, independent from the systems being scanned.  A significant change affecting a church website may include: new hardware, software, or networking equipment, replacement or major upgrades of hardware and software, any changes in the flow or storage of account data, changes to the underlying supporting infrastructure, any changes to third party vendors/service providers.

Vulnerabilities identified by scans performed after significant change, that are scored 4.0 or higher by the CVSS (Common Vulnerability Scoring System), must be resolved and re-scans conducted, as needed.

Service Providers

A current and accurate list of approved service providers must be maintained including contact details and a description of the services provided.  The list must include third party service providers that payment card data is shared with or that could impact the security of payment card data.  This includes any third-party delivered service that may:

• Affect processing of card payments via the hosted web interface, face to face and MOTO (mail order/telephone order) payment channels,
• Affect the handling, or protection of payment card data,
• Affect processing of card payments via Vanco Give+ Text or Give+ Mobile payment channels (if available to the NC Synod’s members and donors).

There must be a written agreement with each service provider that includes an acknowledgement by the service provider of their responsibility for securing the payment card data they possess, process or transmit on the NC Synod’s behalf, or to the extent that the service provider could impact the security of the NC Synod’s cardholder data and/or sensitive authentication data.

Due diligence must be exercised before engaging with any service providers that may affect the NC Synod’s cardholder data environment, card payment processing or handling of payment card data.  For example, when engaging a third-party data destruction company, perform checks necessary to verify the potential supplier's ability to fulfil their PCI DSS responsibilities.

For the NC Synod’s use of the Approved payment methods to remain eligible for the PCI DSS SAQ A, the service providers ACS Technologies and Vanco Payment Solutions must maintain their status as validated PCI DSS compliant service providers.

Service providers’ compliance with PCI DSS will be monitored and checked at least annually

Any agreement with a service provider must make clear which PCI DSS requirements are to be managed by the service provider, and which will be the responsibility of the NC Synod.

Security Incident Response

Security incidents must be managed in an efficient and time effective manner to make sure that the impact of an incident is contained and the consequences for both the church and for church members and donors are limited.

A security incident response and escalation procedure must be created.  See Appendix C.

The plan must include:

• Incident response roles and responsibilities
• Communication and contact strategies, including notification of payment brands and acquirers, at a minimum.
• Incident response procedures with specific containment and mitigation activities for different types of incidents.
• Business recovery and continuity procedures, to help the church continue to operate safely in the event of a security incident or a data breach.
• Data backup processes, as backups may help to identify the source of a breach, and what data was exposed, and help to recover quickly following an incident.
• Analysis of legal requirements for reporting compromises.
• Coverage and responses of all critical system components.
• Reference or inclusion of incident response procedures from the payment brands based on review of both acquirers’ and payment brands' guidance on what to do if compromised.

In the event of a suspected (or proven) compromise to payment card data your security incident response plan must be followed.

Copies of the security incident response plan shall be made available to all relevant staff members.

You must take steps to ensure that the incident response primary contact, other security incident response team members and all relevant staff understand the security incident response plan and what is expected of them.

The nominated individual (incident response primary contact or other security incident response team member, in their absence) must investigate each reported incident.

Security Awareness

All those handling payment card data, must be aware of the security policies and procedures and the importance of maintaining the security of payment card data.

The policies and procedures outlined above must be incorporated into Church administrative practice to maintain a high level of security awareness. The protection of sensitive data demands regular training of all staff, volunteers and contractors.

Security awareness training must include awareness of threats and vulnerabilities that could impact the security of church systems, including but not limited to: phishing and related attacks, social engineering.

Review handling procedures for sensitive payment card data and hold periodic security awareness meetings to incorporate these procedures into regular Church administrative practice.

Distribute this security policy document to all staff and volunteers. All staff and volunteers are responsible for information security. It is required that all staff and volunteers who process payment card data, confirm that they understand the content of this security policy document by signing an acknowledgement form (see Appendix A)

[1] https://www.pcisecuritystandards.org/

[2] As of January 2025: https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf

[3] As of January 2025: https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/SAQ/PCI-DSS-v4-0-1-SAQ-C-VT.pdf

[4] As of January 2025: https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/SAQ/PCI-DSS-v4-0-1-SAQ-A.pdf