Church AI Governance & Procurement Standard

No single framework adequately covers the full range of risks a church faces when procuring AI. The strongest standard should combine:

1. NIST for organizational governance, risk management, testing, privacy, cybersecurity, and supplier due diligence.

2. UNESCO and OECD for human dignity, rights, inclusion, transparency, fairness, and human oversight.

3. The Rome Call and Christian teaching for moral responsibility, human dignity, the common good, and the proper relationship between persons and machines.

4. FTC, ICO, PCI SSC, EEOC, W3C, AICPA, CSA, and EU guidance for privacy, accessibility, employment, payment security, vendor assurance, data portability, and exit planning.

A church should never approve an AI product merely because it is popular, inexpensive, easy to use, described as “Christian,” or recommended by another congregation.

Core sources for the entire standard

NIST — Artificial Intelligence Risk Management Framework

This should be the principal operational foundation. The AI RMF organizes institutional responsibility through four continuing functions:

• Govern: establish accountability, policy, roles, values, and oversight.

• Map: understand the system, intended use, users, context, data, and possible harms.

• Measure: test accuracy, reliability, privacy, security, bias, and other trustworthiness characteristics.

• Manage: decide whether to approve, restrict, modify, monitor, suspend, or reject the system.

NIST states that risk management should apply throughout the AI lifecycle rather than ending when a purchase is approved. AI RMF 1.0 remains the current framework, although NIST is revising it; the toolkit should therefore date-stamp its crosswalk and review NIST developments annually. (NIST)

NIST — AI RMF Playbook

The Playbook translates the framework into suggested actions and documentation practices. It is particularly useful for constructing approval forms, risk registers, assigned responsibilities, review schedules, testing records, and conditions of deployment. NIST cautions that it is not a universal checklist; churches should select controls proportionate to the risk and sensitivity of the proposed use. (NIST)

NIST — Generative AI Profile

This is the most important supplement for chatbots, image generators, transcription systems, sermon assistants, pastoral tools, and other generative applications. It addresses risks such as confabulation, information integrity, privacy, harmful content, misuse, human overreliance, cybersecurity, and opaque supply chains. (NIST)

UNESCO — Recommendation on the Ethics of Artificial Intelligence

UNESCO supplies the standard’s global human-rights and human-dignity foundation. Its policy areas include ethical impact assessment, governance, data policy, education, health, culture, inclusion, gender, environmental effects, monitoring, and evaluation. It repeatedly emphasizes human oversight, fairness, transparency, accountability, and protection of fundamental rights. (UNESCO)

OECD — AI Principles

The OECD principles are especially useful for contract requirements concerning:

• Human agency and oversight

• Privacy and fairness

• Transparency and explainability

• Robustness, safety, and security

• Traceability

• Accountability

• Safe override, repair, or decommissioning

• Ongoing risk management

The principles were updated in 2024 to address developments including generative AI, disinformation, data security, and foreseeable misuse. (OECD)

Rome Call for AI Ethics

The Rome Call contributes six concise moral principles suitable for a church procurement covenant:

1. Transparency

2. Inclusion

3. Accountability

4. Impartiality

5. Reliability

6. Security and privacy

Its governing conviction is that AI should serve human beings rather than reduce persons to objects of prediction, manipulation, or replacement. (romecall.org)

Vatican — Antiqua et Nova: On Artificial and Human Intelligence

This provides a substantial Christian theological foundation for evaluating claims about machine intelligence, personhood, human replacement, pastoral care, education, work, relationships, truth, and responsibility. It is particularly valuable for ensuring that procurement remains governed by a Christian anthropology rather than by capability or efficiency alone. (Vatican Press)

1. Vendor assessment questionnaire

Strongest primary sources

NIST — Cybersecurity Supply Chain Due Diligence Assessment Quick-Start Guide, SP 1326

Published on July 8, 2026, this is the strongest current government source for supplier due diligence. It provides an implementation-ready approach to investigating prospective technology suppliers, including provenance, ownership and control, resilience, foundational cybersecurity practices, and deeper supply-chain dependencies. (NIST)

NIST — Cybersecurity Supply Chain Risk Management, SP 800-161 Rev. 1

This provides the deeper organizational framework for assessing risks in products, services, developers, subcontractors, infrastructure providers, and technology supply chains. It is useful for determining what evidence a church should require before entering a contract. (NIST Computer Security Resource Center)

Cloud Security Alliance — AI-CAIQ v1.1

The AI Consensus Assessments Initiative Questionnaire is the strongest ready-made AI vendor questionnaire. Its current version addresses AI governance, model integrity, security, privacy, audit, lifecycle controls, resilience, and evidence supporting vendor answers. (Cloud Security Alliance)

Cloud Security Alliance — CAIQ-Lite and CCM-Lite

This is the better option for small and mid-sized churches. CAIQ-Lite contains a reduced set of cloud-vendor security questions across core control domains and can be combined with a shorter church-specific AI supplement. (Cloud Security Alliance)

AICPA — SOC Suite of Services

A SOC 2 report can provide independent assurance concerning controls relevant to security, availability, processing integrity, confidentiality, and privacy. It is valuable evidence, but it is not proof that an AI system is accurate, unbiased, doctrinally sound, pastorally appropriate, or safe for a particular church use. (AICPA & CIMA)

Essential vendor questions

The questionnaire should require documentary answers to questions such as:

• What exact service, model, model version, and infrastructure will process church information?

• Is the vendor the model developer, a reseller, an interface provider, or an integrator?

• Which subcontractors and subprocessors receive data?

• In which countries is information stored, processed, backed up, or accessed?

• Is customer content used for model training, evaluation, product improvement, advertising, or profiling?

• Can all training and secondary-use settings be contractually disabled?

• What information is retained in prompts, chat history, logs, metadata, backups, safety systems, and abuse-monitoring systems?

• What independent security assessments exist?

• Has the vendor experienced material breaches, model failures, government enforcement, or litigation?

• What is the incident-notification period?

• What technical and human controls prevent unauthorized access?

• Can the church inspect audit records and receive evidence of compliance?

• How are model changes communicated?

• Can the church suspend processing immediately?

• Can all information be exported and securely deleted?

• What happens if the vendor is acquired, closes, changes models, or materially alters its terms?

A vendor’s refusal to answer a material question should itself be recorded as a risk, not treated as an administrative inconvenience.

2. Data-retention and deletion requirements

Best sources

NIST — Privacy Framework

The NIST Privacy Framework provides the broadest vendor-neutral structure for governing information throughout its lifecycle: collection, use, sharing, retention, logging, transformation, disclosure, and disposal. It is designed for organizations of different sizes, industries, and jurisdictions. (NIST)

FTC — Protecting Personal Information: A Guide for Business

The FTC advises organizations not to collect or retain sensitive information without a legitimate need. It recommends a written retention policy identifying what is retained, why it is retained, how it is protected, how long it is kept, and how it is securely destroyed. (Federal Trade Commission)

FTC — Vendor Security Guidance

This is particularly useful for contract language. The FTC recommends putting security expectations in writing, specifying how vendors may use, share, sell, retain, and delete information, and independently verifying—not merely accepting—the vendor’s assurances. (Federal Trade Commission)

ICO — AI and Data Protection Risk Toolkit

The UK Information Commissioner’s toolkit provides practical questions concerning accountability, lawfulness, transparency, accuracy, security, data minimization, fairness, individual rights, and AI lifecycle risks. The current guidance is under review following recent UK legal changes, so any legal conclusions should be checked against the updated version. (ICO)

FTC — COPPA Six-Step Compliance Plan

Although COPPA generally does not apply directly to many nonprofit churches, its principles provide an important procurement benchmark for children’s information: minimize collection, retain it only as long as necessary for the stated purpose, require written security assurances from service providers, and securely delete it afterward. (Federal Trade Commission)

Contract requirements

The procurement standard should require the contract to state:

• Every category of information collected

• The purpose for each category

• Whether prompts and outputs are retained

• Whether data enters model training or product-improvement systems

• Retention periods for active systems, logs, backups, caches, and abuse-monitoring records

• Whether deletion removes information from derived datasets and indexes

• How long deletion takes

• How deletion is verified

• What happens after account closure or contract termination

• Whether data can remain in de-identified, aggregated, or legally required records

• Which subprocessors retain copies

• The church’s right to request early deletion

• The church’s right to receive written confirmation of deletion

“Deleted from the user interface” must not be accepted as equivalent to deletion from operational systems, backups, model-training pipelines, logs, and subprocessors.

3. Rules for pastoral, children’s, donor, personnel, and prayer-request data

A church should classify these categories as restricted or highly restricted, whether or not a particular privacy statute formally applies. Their sensitivity arises not only from identity theft but from the sacred trust, vulnerability, pastoral dependence, and potential spiritual or reputational harm attached to them.

Pastoral and prayer-request information

GDPR — Article 9, Special Categories of Personal Data

In the EU and EEA, information revealing religious beliefs, health, sexual life or orientation, biometric identity, race or ethnicity, and several other categories receives heightened protection. Prayer requests and pastoral records frequently contain several of these categories simultaneously. Even outside Europe, Article 9 offers a valuable sensitivity benchmark. (Eur-Lex)

ICO — What Is Special Category Data?

The ICO guidance helps institutions recognize that sensitive information may be explicitly supplied or inferred by a system. This is important because AI may infer illness, family crisis, religious practice, sexuality, disability, or emotional condition from apparently ordinary text. (ICO)

Recommended rule: Pastoral notes, confessional communications, spiritual-direction records, counseling information, prayer requests, abuse disclosures, funeral information, and crisis communications must not be entered into a public or consumer AI system.

Children’s information

FTC — COPPA Compliance FAQ

COPPA identifies children’s names, contact information, identifiers, photographs, videos, audio recordings, precise location, and other online information as protected categories in covered services. It also gives parents rights concerning notice, consent, access, deletion, security, and limits on collection. (Federal Trade Commission)

Recommended rule: No child’s name, face, voice, photograph, location, disability, pastoral disclosure, family circumstance, health information, behavioral record, or prayer request may be entered into an AI system without a formally approved purpose, parental authorization where appropriate, documented vendor review, and the minimum necessary data.

Donor and payment information

PCI Security Standards Council — PCI DSS

PCI DSS is the authoritative baseline for systems that store, process, or transmit payment-card account data. It should govern any AI-enabled donation, payment, donor-service, or financial-processing system that touches cardholder data. (PCI Security Standards Council)

PCI DSS covers payment-card data, not every form of bank-account information, donor history, wealth estimate, or giving profile. Those additional categories require separate privacy and fiduciary controls. (PCI Security Standards Council)

Recommended rule: AI must not receive full card numbers, security codes, bank credentials, tax identifiers, or unredacted financial records. Donor segmentation and fundraising prediction should undergo ethical review for manipulation, discrimination, confidentiality, and mission alignment.

Personnel and applicant data

EEOC — Artificial Intelligence Employment Resources

The EEOC’s official collection addresses disability discrimination, adverse impact, hiring algorithms, employee assessment, accommodations, and automated employment decisions. Employers remain responsible for discriminatory outcomes even when they use a third-party vendor’s system. (EEOC)

Recommended rule: No AI system may reject, rank, evaluate, discipline, promote, or terminate an employee or applicant without informed human review, documented job-related criteria, accommodation procedures, and bias testing.

4. Human-review requirements

Best sources

European Commission — AI Act, Article 14: Human Oversight

Article 14 provides one of the clearest operational descriptions of meaningful oversight. Human reviewers must be able to understand the system’s capabilities and limitations, recognize automation bias, monitor operation, interpret outputs, disregard or override results, and stop the system where necessary. (AI Act Service Desk)

OECD — AI Principles

The OECD calls for mechanisms preserving human agency and oversight and enabling systems to be overridden, repaired, or safely decommissioned when they present undue harm or unwanted behavior. (OECD)

UNESCO — Ethics of Artificial Intelligence

UNESCO identifies human oversight as essential to protecting dignity, autonomy, fairness, and fundamental rights. (UNESCO)

Required church controls

A meaningful human-review rule should state:

• AI may advise; an accountable person must decide.

• The reviewer must possess authority to reject the output.

• The reviewer must have enough time and relevant competence to evaluate it.

• Review cannot be reduced to clicking “approve.”

• High-consequence outputs require corroboration from primary sources.

• The original human author remains responsible for sermons, pastoral messages, public statements, personnel decisions, safeguarding decisions, financial actions, and theological claims.

• No AI system may make a final decision concerning pastoral care, employment, discipline, financial assistance, child safety, sacramental practice, membership, or emergency intervention.

• The church must identify uses for which AI is prohibited, not merely supervised.

5. Doctrinal and factual reliability testing

Factual-reliability sources

NIST — AI Test, Evaluation, Validation and Verification

NIST emphasizes that trustworthy deployment depends on testing systems in their intended context, using appropriate metrics for accuracy, reliability, robustness, security, bias, privacy, interpretability, and safety. (NIST)

NIST — AI Resource Center

The AIRC provides implementation resources for the AI RMF and access to testing, evaluation, verification, and validation methods. (NIST AI Resource Center)

NIST — AI RMF Measure Function

NIST recommends documenting test sets, metrics, procedures, tools, limitations, and results so that evaluation can be repeated rather than based on an impressive demonstration or vendor claim. (NIST AI Resource Center)

NIST — Evaluation of Machine-Generated Reports

This research is useful for testing AI-generated reports, lessons, policies, and theological summaries. It proposes evaluation for completeness, accuracy, and verifiability, including whether claims can be traced to supporting sources. (NIST)

Doctrinal reliability

There is no universal technical test that can certify an AI product as “Christian,” “biblical,” or doctrinally reliable. The standard should therefore require a church-controlled doctrinal test corpus drawn from the congregation’s or denomination’s officially authorized sources.

The test should include:

• Scripture passages in the church’s approved translations

• Creeds and confessions

• Catechisms or doctrinal statements

• Sacramental teaching

• Ecclesiology and ministry standards

• Teaching on human dignity, sexuality, marriage, race, disability, poverty, violence, death, grief, and pastoral care

• Denominational polity

• Questions on contested teachings where traditions differ

• Deliberately misleading prompts

• Requests for fabricated biblical quotations or nonexistent church rulings

• Tests for whether the system clearly admits uncertainty

A theologically fluent answer is not necessarily a faithful answer.

The review panel should include clergy, theologians, Christian educators, safeguarding leaders, and representatives of communities likely to be harmed by confident doctrinal error. The Rome Call and Antiqua et Nova can supply broad Christian ethical principles, but local doctrine must be evaluated against the church’s own recognized authorities. (romecall.org)

6. Accessibility and bias assessment

Accessibility

W3C — Web Content Accessibility Guidelines 2.2

WCAG 2.2 is the leading international standard for digital accessibility. It addresses access for people with visual, auditory, physical, speech, cognitive, learning, language, and neurological disabilities. W3C recommends using the latest version when creating or updating accessibility policy. (W3C)

The church standard should normally require WCAG 2.2 Level AA for member-facing web applications and content, while also requiring direct testing with assistive technologies and disabled users. A vendor’s unverified claim of WCAG compliance is insufficient. (W3C)

Bias and discrimination

NIST — Identifying and Managing Bias in Artificial Intelligence, SP 1270

This is the principal NIST source for understanding systemic, computational, and human forms of bias throughout an AI system’s lifecycle. It emphasizes that harmful bias can arise without deliberate discriminatory intent. (NIST)

NIST — Mitigating AI/ML Bias in Context

This project applies a socio-technical approach to testing bias within the actual context in which a system will be used. That is important for churches because a tool that performs acceptably in a generic benchmark may still fail in multilingual, disabled, rural, low-income, racially diverse, or denominationally specific contexts. (NIST Computer Security Resource Center)

EEOC — AI Employment Guidance

Use the EEOC resources whenever AI influences hiring, volunteer selection, performance, promotion, discipline, or workplace accommodation. (EEOC)

Required testing populations

The church should test performance across:

• Race and ethnicity

• Sex and gender

• Age

• Disability and assistive-technology use

• English proficiency and multilingual communication

• Accent and speech differences

• Economic and educational background

• Different Christian traditions

• Rural and low-bandwidth environments

• Children, adolescents, older adults, and vulnerable persons

7. Cybersecurity review

Best sources

NIST — Cybersecurity Framework 2.0

CSF 2.0 is the principal cybersecurity governance framework for organizations of all sizes. Its functions—Govern, Identify, Protect, Detect, Respond, and Recover—can be incorporated directly into the church’s vendor review and annual assessment. (NIST)

NIST — Cybersecurity Supply Chain Risk Management

Use this for examining vendor ownership, development processes, subcontractors, software dependencies, update practices, resilience, and product provenance. (NIST Computer Security Resource Center)

Cloud Security Alliance — Cloud Controls Matrix and CAIQ v4.1

The current CCM includes 207 controls across 17 cloud-security domains, while the CAIQ converts those controls into vendor questions. It is useful for larger churches, denominations, seminaries, and church networks with professional IT capacity. (Cloud Security Alliance)

AICPA — SOC Overview

This explains the role of independent assurance reports in managing outsourcing and third-party risk. (AICPA & CIMA)

Required evidence

The vendor should provide, where proportionate:

• Recent SOC 2 Type II or equivalent independent assessment

• Penetration-testing summary

• Vulnerability-management process

• Encryption standards

• Multifactor-authentication support

• Role-based access control

• Audit logging

• Breach-response procedures

• Incident-notification commitment

• Business continuity and disaster recovery

• Software-development security practices

• Subprocessor register

• Data-location information

• Model and infrastructure change-management process

• Evidence that customer data is isolated from other tenants

• Procedures for revoking access and deleting former users

• Procedures for compromised accounts and harmful generated content

The existence of a SOC report should not end the review. The church must examine its date, scope, exclusions, auditor opinion, exceptions, subservice organizations, and customer responsibilities.

8. Pricing and vendor-dependency analysis

Best sources

UK Government — Managing Technical Lock-In in the Cloud

This is one of the clearest public-sector resources on vendor dependency. It distinguishes commercial lock-in from technical lock-in and recommends measuring portability, ownership, switching costs, architecture dependencies, internal skills, open standards, and the time and cost required to move. The guidance was substantially updated in April 2025. (GOV.UK)

UK Government — Managing Spending in the Cloud

This explains consumption pricing, fluctuating costs, committed-use discounts, unused services, spending alerts, and the need for continuous cost optimization rather than relying on the introductory price. (GOV.UK)

FinOps Foundation — FinOps Framework

The FinOps Framework provides a vendor-neutral operational model for technology cost accountability across engineering, finance, procurement, and institutional leadership. (FinOps Foundation)

FinOps Foundation — Rate Optimization

This is useful for evaluating usage-based fees, commitment discounts, negotiated pricing, promotional offers, and the risks of long-term consumption commitments. (FinOps Foundation)

Total-cost analysis should include

• Subscription and license fees

• Per-user charges

• Prompt, token, storage, and API consumption

• Data-egress charges

• Premium security or privacy features

• Identity-management integration

• Implementation and customization

• Staff training

• Legal and procurement review

• Accessibility remediation

• Monitoring and audit costs

• Human-review time

• Records-management costs

• Incident response

• Model or product upgrades

• Migration and export

• Contract termination

• Loss of discounts

• Replacement-system costs

• Productivity losses during transition

A free or inexpensive product may become costly when the church discovers that privacy controls, administrative capabilities, data export, audit logs, or enterprise security require a higher-priced tier.

9. Exit and data-migration plan

Best sources

EU Data Act — Switching Between Data-Processing Services

The Data Act provides a strong model for contractual portability. It addresses switching procedures, machine-readable formats, open interfaces, data and metadata export, technical support, continuity, contractual transparency, and removal of switching barriers. (Digital Strategy)

EU Data Act — Official Regulation

The regulation requires information about available switching procedures, formats, restrictions, technical limitations, open interfaces, charges, exportable data, and support for an exit strategy. These provisions are directly useful as model contract language even where EU law does not govern the church’s agreement. (Eur-Lex)

UK Government — Managing Technical Lock-In

The guidance recommends choosing open standards and formats, retaining ownership and access to data, estimating the time and cost of exit, and periodically testing whether critical services can actually be moved. (GOV.UK)

Exit-plan requirements

Before approval, the vendor must explain:

• What data can be exported

• Which metadata, configuration, prompts, outputs, audit logs, and user permissions can be exported

• Available formats

• Whether formats are documented and machine-readable

• Whether APIs are available

• What data cannot be exported and why

• Export costs

• Migration-support costs

• Notice periods

• Termination penalties

• Maximum transition time

• Continued service during migration

• Backup availability

• Post-termination retrieval period

• Final deletion procedure

• Written deletion verification

• Treatment of subprocessors

• Whether the church can migrate to another vendor or an internal system

• What happens if the provider suddenly discontinues the product

The church may conduct a small export test before committing highly sensitive or operationally essential information to the platform.

10. Annual policy review

Best sources

NIST — AI RMF Core

NIST treats AI risk management as continuous and lifecycle-based. The approval decision therefore needs periodic reconsideration as models, vendors, data practices, laws, ministry uses, and risks change. (NIST AI Resource Center)

FTC — Cybersecurity for Small Business

The FTC recommends monitoring vendors, verifying compliance, and updating contractual security requirements as threats evolve. (Federal Trade Commission)

OECD — AI Principles

The OECD calls for systematic risk management throughout the lifecycle and continued accountability among providers, deployers, users, and other actors. (OECD)

Annual review agenda

Every approved system could be reconsidered at least annually and sooner when:

• The vendor changes its model or terms

• The vendor begins using customer information for training

• A serious incident or breach occurs

• Ownership changes

• A key subprocessor changes

• The church introduces a new use

• The system begins processing more sensitive information

• Applicable law changes

• Material bias, doctrinal error, or factual unreliability is identified

• Pricing materially increases

• A more secure or less intrusive alternative becomes available

The annual decision should be one of five outcomes:

1. Continue without change

2. Continue with additional controls

3. Restrict approved uses

4. Suspend pending remediation

6. Terminate and migrate

Recommended approval rule

The standard could conclude with a presumption proportionate to sensitivity:

An AI system shall not be approved merely because it is useful. It must be shown to be necessary or meaningfully beneficial, proportionate to the ministry purpose, governed by accountable human beings, tested in the context in which it will be used, protective of confidential and vulnerable persons, contractually controllable, financially sustainable, and capable of being safely discontinued.

A church’s first responsibility in AI procurement is not to the product.

It is to the people whose lives, prayers, work, gifts, wounds, children, and trust may pass through it.