Who is responsible for what under a shared-responsibility model?

Under a shared-responsibility model, the vendor is responsible for the security of the platform, meaning infrastructure, encryption, patching, tenant isolation, availability, and backups, and the customer is responsible for security in their use of it, meaning who has accounts, what access they hold, whether MFA is enforced, who has been offboarded, what data is uploaded, and what the organization's own policies allow. Most incidents that end up as a nonprofit's problem happen on the customer side of that line, which is why knowing where the line sits matters more than the vendor's badge count.

The model is borrowed from cloud infrastructure, where it has been the standard framing for years, and it applies the same way to any hosted software. The vendor cannot see or control your staff roster. You cannot patch the vendor's servers. Each side owns what only it can do.

The vendor's side

Physical and network infrastructure, and the hosting providers underneath. Encryption of data at rest and in transit, with the standards named. Isolation between customers' data, enforced at the platform or database layer rather than left to application code. Patching and vulnerability management, with penetration testing on a schedule. Backups, retention windows, and tested restore. Authentication mechanisms: the availability of MFA, session handling, step-up verification for high-impact actions. Logging of security-relevant events and making those logs available to the customer. Subprocessor management, with data processing agreements in place and the list published. Breach detection and notification. External attestation, such as a SOC 2 report, so the above is examined by someone other than the vendor.

The customer's side

Account lifecycle. Creating accounts for the right people, at the right permission level, and removing them the day someone leaves. Stale accounts belonging to former staff and volunteers are the most common finding in any access review.

MFA enforcement. The vendor makes MFA available; the organization decides whether it is required. Where a platform offers organization-wide enforcement, turning it on is the customer's call and the customer's responsibility.

Administrator hygiene. How many administrators exist, whether each has recovery codes stored somewhere safe, and whether a single administrator's lockout would lock the organization out.

What gets uploaded. Client records, health-adjacent information, and financial documents carry obligations that arrive with the data. The vendor's controls protect what is stored; deciding whether it belongs in the system is the customer's judgment.

Integration credentials. Every connected accounting file, email account, or payment processor is an access path the organization granted. Reviewing them periodically is the customer's job.

Policy. An acceptable use policy, an AI use policy, and a data retention decision are organizational documents. The vendor can provide tools and templates; it cannot decide what the organization permits.

Reviewing the logs. A vendor that logs sign-ins and administrator actions has done its part. Someone at the organization looking at those logs, at least when something seems off, is the other half.

Board oversight. NACD's 2025 director guidance on AI governance calls risk oversight a board's core fiduciary responsibility and central to the responsible use of AI systems, and COSO's 2026 publication Achieving Effective Internal Control Over Generative AI applies its internal-control framework to generative AI. That oversight sits with the customer's board, not with any vendor.

Where the line gets blurry

Configuration defaults. A vendor that ships with weak defaults has shifted work to the customer. Ask what the defaults are and what has to be changed.

Data the vendor's AI can reach. If AI features can act on organizational data, the vendor owns the controls on what the AI may see and do; the customer owns the decision about how much autonomy to grant and which staff may invoke it.

Subprocessors. The vendor is accountable for its subprocessors, but the customer's data protection obligations to its own supporters do not transfer. Reading the subprocessor list is a customer task.

How TappHQ divides it

On the vendor side: encryption at rest and in transit with standards named, tenant isolation at the database layer, scheduled penetration testing, a published subprocessor list with retention terms, hash-chained audit logging, and a SOC 2 Type II observation period in progress. On the customer side, TappHQ makes the responsibilities visible rather than leaving them implicit: organization-wide MFA enforcement is available on Pro and Enterprise plans, a daily check flags organizations where a single administrator holds MFA without recovery-code coverage, authentication and administrator events are visible to organization administrators, per-agent safety levels let an administrator set how much an AI assistant may do on its own, and administrators choose which link domains the AI may include. The free AI Use Policy Generator produces the policy document that sits on the customer's side of the line. The split is the same as every hosted platform's. The difference is whether each side can see its half.