Skip to main content

Your data is not in a table with everyone else’s

Most platforms in this market put every customer in one shared database and separate them with a column. CommunityForce gives each organization its own database and its own file storage. That difference is the answer to most of what a security review asks about.

  • FedRAMP certified
  • SOC 2 Type II
  • Section 508
  • FERPA
  • PCI-DSS
Talk to an expertBook a demo

Illustration of two organizations on the platform, each with its own database, its own file storage and its own web address, and nothing shared between them.

Two organizations, two environments

Nothing shared: no common table, no tenant column, no shared bucket

Microsoft Azure

Meridian Community College

meridian.communityforce.com
  • Own databaseApplicants, reviews, awards
  • Own file storageTranscripts, essays, tax documents
  • Own web addressYour branding, your domain

Harbor Foundation

harbor.communityforce.com
  • Own databaseApplicants, reviews, awards
  • Own file storageTranscripts, essays, tax documents
  • Own web addressYour branding, your domain

A separate environment for each organization

Each organization runs in its own private environment: its own database, its own file storage, its own branding, on your own web address. For a reviewer assessing risk, this collapses a long list of questions into a short one. There is no shared table to be queried across, and no tenant-filter bug that could expose one customer’s applicants to another.

  • Separate database

    Your records live in a database of their own.

  • Separate file storage

    Transcripts, essays and tax documents are stored in your own container.

  • Your own web address

    Your branding and your domain, so applicants never leave your identity.

  • Microsoft Azure

    Managed databases, cloud storage and zero-downtime updates.

Who can see what

Applicant records hold financial information, personal circumstances and documents people would not want read by anyone who did not need to. Access is controlled down to the program.

  • Single sign-on

    Staff and students sign in with their existing institutional account over SAML 2.0, so access follows your directory rather than a second password list.

  • Role-based access

    Control what each staff member, reviewer and partner can see and do, including which programs they are allowed to touch at all.

  • Two-factor sign-in

    Optional second factor by email or text, alongside configurable password policies, account lockout and bot protection on public forms.

  • Controls inside the review itself

    Decide which parts of an application each reviewer sees and when, and whether reviewers can see one another’s scores. That supports blind and staged review, a process you can describe to a board step by step.

What an audit will ask

An audit asks what happened, when, and who did it.

  • Activity logging

    Structured logging of activity across the platform, so an audit reads the log instead of reconstructing events.

  • Encrypted throughout

    Encrypted connections across the platform, with credentials held in a managed cloud secrets vault.

  • Never training material

    Phoenix reads your data to answer you. It is never used to train AI models, ours or anyone else’s, and it stays in your environment.

  • Accessibility

    Built to WCAG 2.2 AA. Applicants using a screen reader or a keyboard are applying for the same awards as everyone else, and a form they cannot finish is a program they cannot enter.

  • Your history, imported

    Users, applicants and historical applications come in from spreadsheets through guided templates, so moving platforms does not mean leaving your record behind.

AI, governed

Phoenix, the intelligence behind Copilot and Agents, is designed in alignment with the NIST AI Risk Management Framework and the OWASP Top 10 for LLM applications. What that looks like in practice:

How Phoenix works

  • Off until you turn it on

    AI is enabled per organization, off by default and switched on and governed by your own administrators, with access controlled by role.

  • A person confirms every action

    AI proposes; a change lands only after someone says yes. Award and eligibility decisions are never AI’s to make.

  • Applicant words are data, not instructions

    Nothing an applicant writes can steer the AI. Essays and answers are content it reads, never commands it follows, and every AI run sees only what that one signed-in user is allowed to see.

  • On the record, then gone with the record

    Every AI call and action is in the audit log, and AI-generated artifacts are deleted along with the applicant’s record when erasure is requested.

Send us your security questionnaire

We would rather answer it properly than have you guess from a web page.

Talk to an expertBook a demo