Overview Pricing Security Login Register
Security
The documents, the subprocessors, the data handling, the age gate on the AI features, and what P3 does not have.
Contents
Documents Your reporting The gaps Student data AI features The privacy floor Where the data is Subprocessors Access control Change log Ask us
Documents
Published means it is on this site now. On request means we send it by email, we just do not publish it openly. In preparation means it does not exist yet, and we say so rather than link to nothing.
W-9
Signed, 2026. EIN 82-3649154.
IRS 501(c)(3) determination letter
Establishes P3's exempt status for your supplier record.
Enterprise Subscription Terms
Version 2026.2, at a permanent URL that is never edited after publication.
Data Sharing Addendum
Version 2026.2. Section V carries the 10 student privacy floor.
Subprocessor list
Every vendor that processes personal data, with its purpose and its region.
Read below
Accessibility Conformance Report
VPAT 2.5 WCAG, self-assessed. In preparation, and when it is published it will say which criteria we do not meet.
In preparation
Certificate of Insurance
Commercial general liability and cyber liability. Your institution can be named.
On request
HECVAT 4.1
Completed for your institution on request, and sent with the answers rather than with a promise to answer.
Security questionnaire response
Your own form, completed. We do not require you to use ours.
Every published version of the Enterprise Subscription Terms and the Data Sharing Addendum stays at its own permanent address and is never edited after publication, so you can always prove what your institution accepted and on what date.
Your reporting
What P3 observes on the platform, what students report themselves, and the line between the two.
The students who connected a P3 account to your institution.
Activity in the app from day one, with or without a mentor.
Self-reported, from the profile each student fills in themselves.
Student reported
Students report where they go next, in the P3 app.
The gaps
We would rather you read this here than discover it in a security review, because discovering it there costs you a cycle and costs us the deal.
P3 does not hold a SOC 2 report. We are a nonprofit with a small engineering surface, we run on AWS and Cloudflare, we publish our subprocessors, and we will complete your security questionnaire. If your process requires SOC 2 today, we would rather you tell us now than at contract stage.
P3 has not commissioned one. The institutional surface is one Cloudflare Worker and one React application, which is small enough to audit by reading, and P3 will support a customer-run assessment of it.
There is no SAML, OIDC or SCIM. Administrators sign in with a six digit single-use code sent to their work email. The stated upgrade path is Cloudflare Access, which brokers SAML and OIDC on infrastructure P3 already uses, and no date is given because none has been committed.
P3 publishes no status page, commits to no uptime percentage, and offers no service credits. We will tell your administrators in advance about planned maintenance where we reasonably can.
There is no public API and no connector to a student information system or a learning management system. Nothing P3 sells requires access to either one.
P3 also does not guarantee that any student is matched with a mentor. 154 approved mentors serve every institution on P3, and that number is published on the pricing page and inside the dashboard rather than kept in a sales conversation.
Student data
Students register with P3 directly and consent to P3 directly. P3 is the controller of that data, your institution receives aggregated reporting rather than student records, and P3 is not a school official under FERPA.
The account a student created
Name, email, and the profile fields a student filled in themselves: education goal, the help they are looking for, industry interest and meeting rhythm.
What a student did on P3
Mentor matches, conversations, milestone check-ins, saved opportunities and app activity.
What a student told us about themselves
Outcome milestones require a note before they complete, so a student says in their own words where they started work or which major they chose. The career timeline holds the education and roles they entered, with organization and years. All of it is volunteered, and none of it is verified.
The institution a student claimed
One organization identifier, set by the student, from your join code or link, and removable by the student at any time.
Anything from your systems
No student information system record, no learning management system record, no roster, no transcript, no financial aid record. P3 has no feed from any of them and asks for access to none of them.
A verified outcome record
P3 holds no registrar or employer record. Graduation, major, first role and employer reach P3 only when a student volunteers them, in a milestone or their own career timeline, and P3 does not verify any of it against your systems or anyone else's. There is no GPA, no credit hours, no salary, no credential award from an awarding body, and no enrollment verification.
Demographics or location
No race, ethnicity, first generation status, Pell eligibility or home address. P3's records carry no location field. Analytics city and region are derived from a device's network address and are never treated as where a student lives.
Any cost data about your institution
P3 holds none, which is why no dollar figure of any kind appears anywhere in the dashboard.
AI features
Pulse AI and the CV review send student text to Anthropic, so they are limited to students aged 18 and older. A younger student cannot reach them and no call is made for them.
Ages 18 and older
The gate is applied where the screen renders and again where the request is made, so a stale link or a saved bookmark reaches an explanation rather than a conversation. Everything else in P3, including opportunities, career pathways, the open question pool and mentor video answers, is open at every age.
Anthropic processes the message
Anthropic, PBC is named in the subprocessor list below, with its region, and it is covered by the same 30 days notice as every other vendor on that list.
It links to a fixed list, not to the open web
Pulse answers may only link to URLs on a curated list P3 maintains, which is how a student gets a working link to federal student aid rather than a plausible address the model invented.
It cannot see your dashboard
Pulse runs on the student side of P3, against that student's own profile and history. It has no access to institutional reporting, and no prompt from a student can return your figures.
The privacy floor
This is the commitment your data governance office will care about most, so it is written here in the words we would use out loud.
No figure representing fewer than 10 students appears anywhere in the partner dashboard or in any export. Where showing the remaining figures would let a hidden one be worked out by subtraction, we hide a second one as well. This is the same threshold state education agencies use in public reporting, and it is a commitment in your Data Sharing Addendum rather than a setting somebody at P3 can change.
Both the aggregation and the suppression happen on P3's servers. A suppressed value never reaches your browser, because there is no view and no export that contains one. There is also no individual level export, deliberately and permanently, because offering one would defeat the commitment we just made you.
The practical consequence, stated up front rather than discovered later: a small cohort will see totals and a growth curve, and will see most breakdowns held back until the cohort grows. The dashboard tells you how many students each view still needs.
One list on the dashboard is about people rather than figures: Enrollment, who has joined. For an institution registered from September 17, 2026, it shows each student by first name and last initial, when they joined, and whether they have a mentor, and the mentors who name the institution on their profile. Students are told this on the join screen before they join.
The roster carries no email address, phone number, message or free text, is shown to owner and admin accounts only, and is not exported. What a student does in P3 is never shown for one person: every activity figure follows the floor above.
No endpoint that returns tenant analytics, membership or billing data accepts an organization identifier. The organization is read from a server-side session row, so a request cannot ask for someone else's data by changing a parameter. That removes the whole class of problem as a property of the design rather than as a control we have to defend.
Not for an administrator, not for an owner, not on request, and not for a fee. Offering one would defeat the suppression commitment, so it does not exist. You get your own aggregates as CSV and as a print ready briefing, both generated from the same stored figures the dashboard renders, so the page and the export cannot disagree.
A student adds your institution themselves. From your join link or code, they see exactly what you will and will not be able to see before anything is written, and they can remove it at any time. A student can also pick your institution in the P3 app’s profile, where the app asks them only to confirm the change. P3 does not verify that a student who claims your institution attends it, and has no roster feed that could.
P3 does not take a roster of your students in any form, including a sync with your student information system. Our Data Sharing Addendum deliberately does not claim school official status under 34 CFR 99.31(a)(1). Students add your institution themselves, and the way to reach them at scale is an advisor send: a message your own staff send, from a person the student already trusts.
Where the data is
P3 stores personal data governed by the Data Sharing Addendum in United States regions of its cloud providers, and P3's subprocessors are entities organized in the United States. Certain edge computing, content delivery and network security functions may process data in transit at points of presence outside the United States. That processing is transient, is incidental to delivering the service, and does not result in personal data being stored outside the United States.
We state it that way because it is accurate. A flat claim that nothing ever leaves the United States would be easier to read and would be wrong, since edge compute and content delivery run at points of presence worldwide by default.
Subprocessors
We give your administrators at least 30 days notice by email before adding one. If you object on documented data protection grounds within that period we discuss it in good faith, and if we cannot resolve it you may terminate.
Amazon Web Services, Inc.
United States
Core platform infrastructure and the application database.
Cloudflare, Inc.
United States, with transient edge processing worldwide
Edge compute and databases for the enterprise gateway, Pulse AI, Conversations and the web app. Network security and content delivery.
Anthropic, PBC
AI features: the Pulse assistant, Discover, CV review, and automated moderation of mentor and student messages.
Algolia, Inc.
Search indexes for mentors, students, opportunities, posts and questions. This is the index the institutional dashboard reads.
Google LLC (Firebase)
Mobile analytics, crash reporting and deep links.
Amplitude, Inc.
Product analytics.
Retool, Inc.
Internal administration console used by P3 staff.
Twilio Inc. (SendGrid)
Transactional email.
Resend
Administrator sign-in codes and safeguarding alert delivery.
Intercom, Inc.
Customer messaging and support.
Functional Software, Inc. (Sentry)
Error and crash monitoring, including session replay.
Stripe, Inc.
Payments, invoicing and quotes. Stripe never receives student data.
3Advance, LLC
Engineering delivery partner for the P3 platform.
Stripe appears on this list because it processes your institution's billing contact and payment details. It never receives student data.
Access control
There is no password to leak and no single sign-on to configure, which is a tradeoff rather than a feature, and here is exactly what it means.
Six digit single-use codes
A code, not a clickable link, because university mail security often follows links automatically and would spend a magic link before your administrator did. Codes are single use, expire in ten minutes, allow five attempts and are stored salted and hashed, so reading the database yields nothing usable.
Your own domains only
An invitation can only be sent to an address at an email domain your institution holds here: one someone active on your team already uses, or one P3 added because you asked. Adding one is a person at P3 acting on your request rather than a DNS check, and it is written into your own audit trail with who did it and when. There is no way to invite an arbitrary address into your tenant.
Sessions you can end
A session is an opaque random identifier in a same-origin, HttpOnly cookie, backed by a row P3 can revoke. Removing an administrator revokes their sessions in the same transaction, so access ends on their next request. A stateless signed token cannot answer that question honestly and we did not use one.
Three roles
Owner (billing, members and data), admin (members and data) and viewer (data only). Roles are enforced on the server by re-reading the membership row, never by hiding a button.
An audit trail you can export
Every sign-in, member invitation, role change, member removal, metrics read and export is written to an append-only log with the actor, the organization, the timestamp and the source address. It is your log, and an owner or admin downloads it as a CSV from Settings. A wrong code is logged too, for P3's own security monitoring, because until a code is right it names no institution.
Change log
Dated, so a reviewer can tell whether they are reading something current.
September 19, 2026
Three corrections. Invitations are limited to email domains someone active on your team already uses; P3 does not check domains by DNS record, as this page had said. A student can also pick your institution in the P3 app's profile, which asks them only to confirm, without the join screen's lists. Failed code attempts are not in your institution's audit trail, which owners and admins now download from Settings.
September 17, 2026
Enrollment: institutions registered from this date see each student by first name and last initial, when they joined and whether they have a mentor, and the mentors who name the institution. Version 2026.2 of the Terms and the Data Sharing Addendum, and the join screen, say so; the reporting floor and the school official position are unchanged.
September 8, 2026
An AI features section was added, stating that Pulse AI and the CV review are limited to students aged 18 and older, that the gate is enforced at render and at the request, and that Pulse can only link to a curated list.
September 7, 2026
Subprocessor list expanded to name Cloudflare, Anthropic, Algolia, Resend and Stripe, each of which processes personal data today and none of which appeared on the previous schedule.
The data residency statement was rewritten to describe P3's actual configuration, including transient edge processing outside the United States.
Partner dashboard sign-in moved to six digit single-use codes on verified institutional domains, with server-side revocable sessions.
Ask us
Tell us which control, which criterion or which document, and we will answer it or tell you plainly that we cannot.
Email team@pulseofp3.org Back to pricing
If your process requires SOC 2 today, say so at the start rather than at contract stage. We would rather lose a cycle than waste yours.
Overview Pricing Security Register Login
The Pulse of Perseverance Project, Inc., a 501(c)(3) nonprofit corporation incorporated in Illinois. EIN 82-3649154. team@pulseofp3.org · Privacy