Effective 14 October 2026. This addendum forms part of the service agreement between People Purpose Corporation and the client company that subscribes to Quadrant.
This is a draft. It has not been reviewed by a lawyer. It was written from the source code of the product, so that it describes what the software actually does rather than what a template says it should do. It is published so that a client's counsel can read it and mark it up. Until a lawyer has reviewed it and Rod has signed off, treat it as an honest description of the system and a proposed set of commitments, not as executed contract language.
Nothing in this document was guessed at. Where a fact could not be established from the source code it was left blank rather than invented, and the remaining open items are listed together in section 20.
Contents
People Purpose Corporation ("People Purpose", "we", "us"), a corporation incorporated in Manitoba, Canada, operating the Quadrant service at disc-quadrant.com. Registered office: 7 Fox Run, Kleefeld MB, R0A 0V2, Canada. Contact: Rod Penner, rod@people-purpose.com.
People Purpose is a sole-operator business. One person operates the platform, holds the production credentials, and answers privacy correspondence. That is stated plainly because it is relevant to several of the commitments below, particularly audit and breach response.
The Client ("you"), the company that has subscribed to Quadrant and whose employees and applicants are the subject of the processing described here.
This addendum covers personal information about your people — your job applicants, your employees, and the people your staff enter into Quadrant — that we process because you use the service.
It does not cover:
Applicable law. The federal Personal Information Protection and Electronic Documents Act (PIPEDA) applies to this processing. If you are a provincially regulated employer in Alberta or British Columbia, the Personal Information Protection Act of that province applies to your employee and applicant information instead, and both statutes have specific rules for "personal employee information" that let an employer collect, use and disclose it without consent where that is reasonable for establishing, managing or ending the employment relationship, provided the individual has been given notice. Where those rules apply, the notice obligation is yours, not ours. Canada's anti-spam legislation (CASL) governs commercial electronic messages.
Quebec. Quebec is not a market we sell into. We have not built for Quebec's Law 25 and we do not claim to comply with it. If you have employees or applicants in Quebec, tell us before you sign, because this addendum does not cover you.
Quadrant sits in the middle of three different relationships. Most confusion about privacy in a product like this comes from mixing them up, so they are kept separate throughout this document.
Nothing in Quadrant charges a job seeker anything. Candidate-side use of the product is free and always will be.
You decide the purposes. For your applicants and your employees, you are the organisation that decides why the information is collected and what it is used for. You choose to open a role, to invite an applicant, to send your team the assessment link, to run a review, to write a note about someone. You are responsible under PIPEDA (or Alberta or BC PIPA) for having a basis to do those things, for telling the individual what you are doing, and for making sure your own use is reasonable.
We process on your instructions. We hold and handle that information to deliver the service to you. We do not decide, for your people, what the information is for.
Canadian privacy law does not use the words "controller" and "processor" the way European law does. It puts the accountability on the organisation that has the information, and lets that organisation transfer it to a third party for processing under contract while remaining accountable for it. This addendum is that contract. If your counsel prefers the controller/processor vocabulary, you are the controller and we are the processor, and we will not argue about the label.
There are places where we are not acting on your instructions. Rather than bury them, here they are.
Anyone can take the assessment on our public site, use the leadership tool, or use the read-a-person tool without any connection to a client company. The assessment and read-a-person runs are filed to our own platform account, not to yours; a leadership read is not filed to any account at all, since it belongs to no organisation. Either way, none of it reaches your dashboard. We decide the purposes for those. If one of your employees uses a free public tool on their own time with their own email, that record is ours, not yours, and it is not visible in your dashboard.
People who ask for our emails go on our own subscriber list. Consent is recorded when they sign up. Every marketing email carries a one-click unsubscribe. That list is ours. We do not add your employees or your applicants to it because they passed through your account.
We use your administrators' account information to operate the account, bill it, and support it. We count the people on your roster each day to set the per-person quantity on your subscription. We use aggregate, non-identifying information about how the product is used to keep the product working. Those are our purposes.
People Purpose does recruiting work as well as software, and keeps its own pool of people who came to us directly. Section 10 explains exactly what does and does not move between that pool and your account today.
We do not receive copies of the emails your account sends to applicants. Those emails go to the applicant, and to nobody at People Purpose.
There is one deliberate exception, and it is not a copy of anything: the accommodation notice on your applicant emails invites a reply to jobs@disc-quadrant.com, which is our address. That is so a person who needs this in another format, or needs more time, always has a working address to write to. We pass any such request on to you; arranging the accommodation is yours to do as the employer — section 4.3 of the Terms sets that out. This carries only what an applicant chooses to write to us, not a copy of anything we sent them.
| Category | What is in it |
|---|---|
| Identity and contact | Name, email address, phone number, company, job title, region. No home or street address is collected from anyone. |
| Application material | Resume text, the uploaded resume file itself, what the person is looking for, current role, answers to the role questions you set, and the flags those answers produce. |
| Assessment answers | The full set of raw answers to the 24 DISC forced-choice items and to the 8 scenario questions (the option the person picked, and the order the options were shown in), stored verbatim. Records taken before 14 October 2026 hold the older character items and most/least blocks instead, and, if the person was later sent the scenario questions by email, those answers too, added to the same record; the older items are kept, and no longer scored or shown. |
| Raw submission archive | A verbatim copy of every assessment as submitted, written before scoring: name, email, answers (including their timing metadata), IP address, user-agent, the raw invitation token, the typed company name, whether a file was attached, and a timestamp. Held so that a failure in scoring cannot lose a submission. Not readable by the product or by any browser; read only by us, by hand. There is not yet a scheduled deletion for it; we clear it by hand. |
| Derived scores | Normalised DISC percentages; primary and secondary style; and two character-trait positions (Humble, Learning), each a 0 to 100 position between two named ends, worked out on our server from the scenario answers. The seven "Where you sit" positions are worked out from the DISC percentages when a page or a ranking needs them and are not stored. New records hold no consistency ("candour") flag. Records taken before 14 October 2026 keep their older derived values (self-rated character measures, on some a behaviour-based rating and gap, and candour flags); those are retained, not shown, and not used in any ranking. For employees, a set of five "how to manage me" preferences. |
| Written narrative | Generated reports, interview kits, fit reads, and role-alignment reads, each stored against the person. |
| Employment and review content | Job description text and files, review scorecards, both the employee's and the manager's ratings and notes, and free-text notes your staff write on an application. |
| Weekly check-ins and 1:1 records | Where you switch weekly check-ins on for a person: their capacity word and optional note, up to five priorities a week and what became of each, their asks and the responses, the shared 1:1 agenda, the notes and short answers the manager files for each part of the 1:1, the KPI marks given in the 1:1 with any note, and when each meeting was held and who recorded it. 1:1s recorded in August 2026, when the meeting page briefly offered recording, also hold a transcript. Each team member also has a task list, with who added each task and whether it is done, and two sharing switches, with who last changed each one and when. |
| Interview material | Interview transcripts your staff paste in, up to a large size limit. |
| Development records | Growth Program state and progress, including the person's raw quiz answers and a free-text reflection, and certificates carrying their name and company. |
| Account and technical | Login records held by our authentication provider, including email, password hash, last sign-in and email-confirmed timestamps. The IP address of whoever submits an assessment, stored on the assessment record and used to rate-limit submissions. The IP address of anonymous users of the read tool, stored with a date. Timestamps, and how long a person took to complete the assessment. The email address of the staff member who took each action, stamped on stage changes, notes, reads and reviews. |
We do not ask anyone for health information, race, religion, sexual orientation, union membership, criminal record, or financial details, and no field in the product requests them. But several fields are free text — resumes, notes, interview transcripts, job descriptions, the read-a-person input — and a person typing into a free-text box can type anything. What goes into those boxes is under your control, not ours. If your staff type sensitive information into a note, it is stored as typed.
The assessment is a working-style questionnaire and eight scenario questions that place a person on two character-trait spectrums. It is not a medical or clinical instrument and is not offered as one.
We may process your people's information only to provide and support the service. Concretely, that means:
We will not sell your people's information. We will not use it to train a general-purpose model of our own. We will not use it to market to your people. We will not disclose it to another client company. The one place where the boundary between accounts has historically been imperfect is described in section 10, in full.
Your instructions to us are: the service agreement, this addendum, and what your staff do in the product. If you want us to do something outside that, put it in writing to rod@people-purpose.com.
If we think an instruction would put us in breach of Canadian privacy law, we will tell you and we will not carry it out until it is resolved.
If we are legally compelled to disclose your people's information — a court order, a warrant, a lawful demand — we will tell you before we comply, unless the law forbids telling you.
Three things close an application automatically, and nothing else does. An answer to a role question that fails a hard requirement you set, or a hard-requirement question left unanswered, closes the application at submission (section 9.3). A recorded screening interview or an assessment that the applicant does not finish within the five days they are given closes it as well (section 9.4). Beyond those three there is no code path in Quadrant that closes or rejects an applicant without a person clicking to do it. The assessment informs hiring decisions. It does not make them, and it is not a measure of whether someone can do the work.
Three calculations run automatically and you should know how each one behaves.
When a role has zones, the product can rank people against them. The zones are suggested by AI from the job description and apply unless the employer changes them; the number itself is arithmetic, not AI. The style half compares where the person sits on the "Where you sit" spectrums, which are worked out from their DISC percentages, with the zones set for the role, which are set against how people typically answer; Risk-tolerant to Risk-averse mirrors Deliberate to Fast-paced, and Optimistic to Pragmatic mirrors Autonomous to Collaborative, so each mirrored pair counts once. The character half does the same for Humble and Learning, which are worked out from eight scenario questions. Inside a zone costs nothing. Outside, the cost is the number of percentile points between the person and the zone's edge, read from the spread of real results; for the two character traits, until their spread can be measured, it is the distance along the 0 to 100 line. A spectrum marked "doesn't matter" is left out. The two halves are averaged; a person with no trait answers is ranked on style alone. Applicants are scored this way before any offer. Until 14 October 2026 the spectrums were shown but not used in any ranking; they now are.
This number has not been validated. The code says so itself, in a comment kept in the source deliberately: nobody has run an adverse-impact study on it. It is a sorting aid for a human, and you should treat it as one. Do not use it as a cut-off. The zone edges and the percentile spread were set from 274 real assessments taken up to 13 October 2026, and they have not been tested for adverse impact either.
It appears on your list of applicants and on your talent pool's matches for a role. (The recommendation report in section 9.6 also uses its style half, without showing it, only to break ties in its ranking.) The interview guide, which your staff open with one named candidate in front of them, is not given the number: the server drops it, along with its two sub-scores, before the response leaves us, so the browser never receives it. That page shows each spectrum and trait as a line with the role's zone marked and where the person sits, and turns the ones outside the zone into interview questions. It shows no number. A role's character-trait zones and the person's trait lines appear only to owner, admin and HR logins, to the person themselves on their own page, to a platform administrator (section 13.2), and, once a candidate reaches the offer stage, to anyone holding that role's recommendation report share link (section 9.6).
If your staff ask for it, the product sends a resume and the job description to Anthropic's Claude and asks for a 0-100 number and a short written read on how the experience lines up with the role. That number is stored on the application record. It is a language model's judgment, produced on request by a member of your staff, and it carries the same caution: it is input to a human decision, not a decision.
If you set role questions on a posting, you can mark some answers as hard requirements. An answer that does not meet one, or a hard-requirement question left unanswered, closes the application automatically at submission, and the applicant is shown, before they submit, that the answer closes the application. An answer to a question you did not mark closes nothing: it is stored on the application and shown to your staff to read, and decides nothing by itself. Every decision other than the three automatic closes is made by a person.
If you turn on recorded screening interviews, an add-on, applicants who pass the hard requirements are asked to record answers to nine questions on their phone. The interview may ask one short follow-up per question, six at most. Anthropic's Claude reads the transcript of the answer, with up to 6,000 characters of the candidate's earlier answers in the same interview, and asks one when it judges the answer vague or missing one of the named elements, such as a specific example, that the question looks for; the list of elements is the same for every applicant. Your staff watch the recording. When the interview is finished, its transcript, and only the transcript, is sent to Claude together with the role's title, description and scorecard, with no name field added, and the model returns a written read with quotes, a letter grade of A, B or C, and a suggested next step that our code derives from the letter. That letter is a recommendation. It sorts your list; if the application has no rating yet it fills in the rating field; on a C your staff are offered a "Close, as recommended" button; and the letter and read are evidence in a recommendation report (section 9.6). Advancing or closing the applicant is a click by a person. Finishing the interview moves the application into the screening stage automatically, which closes nothing. The video itself is never analysed by software for appearance, expression, voice or anything else. Deepgram converts the recording to text, fetching each recorded answer, video or audio, from our storage through a link that expires after ten minutes, and normally reads the questions aloud; that spoken audio, follow-ups included, is cached and not deleted. Nothing detects where the candidate looks. Until October 2026 the page also counted how many times it lost focus or was hidden during each answer and showed your staff that number; it is no longer collected or shown, including on older interviews that still hold one, and it was never given to the AI. The consent screen tells candidates about the speech-to-text step and the AI follow-up decision before anything records; wording used before October 2026 mentioned neither. Recordings are deleted when the applicant is closed or the role is filled, and in any case 90 days after the latest invitation; the transcript and the read stay on the application record.
When your staff run an interview in Quadrant's interview tool, the interviewer's notes on each gradable question (up to 4,000 characters each) and the session's transcript, if it has one (up to 120,000 characters, the earliest part dropped beyond that), can be sent to Anthropic's Claude with the role's scorecard. No name field is added, but names that appear in the notes or transcript go with them. The model sets a suggested rating on each question it can grade (strong, acceptable or concern, with a one-line reason) and an overall letter of A, B or C. Questions about style and character are never graded. Each rating is marked as set by the AI, never overwrites a rating a person has already given, and can be changed by the interviewer. The ratings are saved with the interview; once the interview is saved, the overall letter is added to the application's review history. They do not change a stage or send an email.
For a role, an owner, admin or HR user can ask for a recommendation report. It covers open candidates on the role who have some interview evidence. For each of them, Anthropic's Claude receives the candidate's name and the evidence held for them on that role, up to about 150,000 characters: notes, ratings and transcripts from every interview type, including reference calls; screening interview transcripts and their read; earlier reviews; the AI's requirement-by-requirement check and summary of the resume; answers to the application questions, including flagged ones; and your team's notes. Assessment scores are not sent to Anthropic, but interview questions generated where a candidate's results sit outside the role's zones, and the interviewer's notes on them, are. The model returns an A, B or C against each scorecard item with the evidence behind it, an overall letter, strengths, things to watch and a one-line suggestion it is asked to frame as advance to an offer, keep as a backup, or decline. The report ranks candidates from most to least aligned, using only the style half of the fit number in section 9.1, only to break ties, without showing it; the report page itself shows each candidate's assessment profile. The model's scorecard is saved on each application. It is advice to the person hiring, and nothing in the product acts on it. A report can be shared by a signed link that opens it without a login for 14 days; anyone holding the link sees every listed candidate's name, scorecard, resume and assessment profile.
Nothing is automatically advanced on the strength of an answer, a score or a grade. Where a role has the recorded screening interview switched on, every applicant who meets the hard requirements receives the same invitation automatically at submission, carrying the same five-day deadline; nobody is picked or skipped. An applicant who finishes that interview moves into the screening stage automatically, whatever their grade. Beyond that, no branch moves an applicant forward without one of your staff doing it.
The cross-company talent pool is switched off. The scheduled job that would copy people out of a client account into a shared pool returns at its first line unless a server switch is explicitly set to "on". It is still on a daily schedule, and it does nothing.
It is paused because, as written, it strips the marker that identifies someone as a client's own employee. On production it had already mirrored twelve employees across four client companies into the platform pool, reading as recruitable, plus four records stamped with where someone had been hired. That contradicts the guarantee we make to clients. Those copies are being worked through.
Two things follow, and both are commitments under this addendum:
One route does still cross, and it is manual. A platform administrator can place a person from People Purpose's own recruiting pool into a client's pipeline by hand, one at a time. That branch is not behind the pause switch. That is us doing recruiting work for a client, not two clients trading databases.
We use the following services. This is the complete list of third parties that receive your people's personal information today.
| Sub-processor | What it does | What it receives |
|---|---|---|
| Supabase | Database, file storage and login accounts | Everything. All records described in section 6. Resume files, job description files and screening interview recordings are held in private storage buckets and served to your staff through short-lived signed links that expire in ten minutes. |
| Netlify | Hosting and serverless functions | Every request to the service passes through it, so it sees IP addresses and request content in platform logs. Some of our own function logs include names and email addresses. |
| Anthropic | The AI behind reports, reads and drafting | See the breakdown below. This is the sub-processor that receives the most sensitive free text. |
| Deepgram | Speech to text for recorded screening interviews, and the synthetic voice that reads the questions. Only where you have that add-on switched on. | Each recorded answer, video or audio, fetched from our storage through a link that expires after ten minutes. The question text, including any follow-up, which is written from the candidate's previous answer. No name field is added, though anything the candidate says aloud is in the recording. Every transcription request carries Deepgram's model-improvement opt-out (mip_opt_out), so Deepgram may not use the recordings to improve its models. Deepgram offers that opt-out for transcription only, not for the question text sent for speech. |
| Resend | Sending email | Recipient address, name, and the full body of every message we send to your applicants and employees. |
| Twilio | Text-message login invitations. Only while the feature is switched on on our side, and only when one of your owners or admins presses the button for one person, at most 20 attempts in any 24 hours for your account. Separately, our platform administrator can send a test message to a number they choose. | The mobile number your owner or admin typed, and a message holding your company's name, a one-time sign-in link and the sender's email address. Twilio keeps its own record of the number and the message. We keep the last four digits of the number with who sent it, when, and whether it went; our function logs record the first six characters of the number. Phone numbers held on applicant, employee or customer records are never sent to Twilio. |
| Stripe | Subscription billing | Your account identifier, your headcount, and your administrator's email address as the billing contact. No applicant or employee data reaches Stripe. |
| Cloudflare (cdnjs) | Serving the browser libraries that read PDF and Word files, and one that draws QR codes on the hiring page | Only the request for the script file itself, which exposes the visitor's IP address to Cloudflare. Resumes and job descriptions dropped into those pages are parsed inside the browser; the file contents do not go to Cloudflare. |
| Google (Google Fonts) | Serving the typefaces our pages use | Nearly every page asks Google's servers for its font files as it loads, so Google receives each visitor's IP address, browser details and our site's name. Nothing else is sent to Google. |
Because this is the question a careful buyer asks, here is the actual list. Each of these runs when a member of your staff asks for the feature, except where noted.
The read-a-person tool also sends Anthropic the raw text your staff paste in and the name of the person it is about. If your staff paste an email a third party wrote, that third party's words go to Anthropic.
Adzuna is used only to pull public job listings in; no applicant information is ever sent out to it.
We will give you at least thirty days' notice by email to your account owner before we add a new sub-processor that will receive your people's information, or before we materially change what an existing one receives. If you object on reasonable privacy grounds within that period, we will work with you to find an alternative, and if there is none you may terminate the affected part of the service without penalty and get a pro-rated refund of anything you have paid in advance.
We have to be honest about the limits of what we know here, because a cross-border statement that turns out to be wrong is worse than no statement.
All of the sub-processors in section 11 are services we buy from third parties, and each of them may process outside Canada. Assume your people's information is processed outside Canada, including in the United States, and is therefore subject to lawful access by the courts and authorities of the countries where it is held. That is the assumption you should plan on and the assumption you should give your people notice about.
The specific region for each service is set out below. Where it says unconfirmed, it means we have not verified it and will not guess.
| Service | Processing region |
|---|---|
| Supabase (database, files, logins) | [[REGION — ROD TO CONFIRM IN THE SUPABASE DASHBOARD]] — the region is not discoverable from the source code. |
| Netlify (hosting, functions, logs) | [[UNCONFIRMED — ROD]] |
| Anthropic | [[UNCONFIRMED — ROD]] |
| Resend | [[UNCONFIRMED — ROD]] |
| Deepgram (speech to text, and the voice that reads the questions, recorded screening interviews only) | [[UNCONFIRMED — ROD]] |
| Stripe | [[UNCONFIRMED — ROD]] |
| Twilio (text-message login invitations, when switched on) | [[UNCONFIRMED — ROD]] |
| Google Fonts and Cloudflare (files fetched by the visitor's browser) | Served from each company's worldwide network of servers, so a request may be handled outside Canada. |
Under PIPEDA a transfer to a third party for processing is a use, not a disclosure, and the organisation that transfers it stays accountable for it. That is us to our sub-processors, and you to us. The Office of the Privacy Commissioner expects the individual to be told, in a way they can understand, that their information may be processed outside Canada. That notice is your obligation to your employees and applicants. We will give you whatever detail you need to write it once the regions above are confirmed.
Whether we hold a signed data processing agreement with each of these providers is being worked through. [[CONFIRM SUB-PROCESSOR DPAs — ROD]]
This section describes only measures that exist in the running system. We claim no certification. We hold no SOC 2, no ISO 27001, and no third-party audit report, and we will not imply otherwise to close a sale.
Separation between client accounts is enforced in application code, not by the database. Server functions connect to the database with a secret key that bypasses the database's own row-level security. Every function then filters by account identifier itself. It works, and every read path in the product is scoped that way, but the guarantee is the correctness of our code rather than a rule the database enforces underneath it. Moving that enforcement into the database is planned work. You are entitled to know it has not happened yet.
Platform administrator access to your account is invited, time-limited and logged, with exceptions you should know. A platform administrator can act inside a client account as its owner only while a support grant is open. Your owner or admin opens one in Settings, under "Support access", for 24 or 72 hours; it closes by itself and can be revoked at any time. For an emergency, such as your own login being the broken thing, a platform administrator can open a four-hour grant without asking, only with a written reason, and your owners and admins are emailed that reason immediately. Each day's use of a grant is logged by area (broad labels, not individual records) and shown to your owners and admins on that Settings page, and the first use of a grant emails them. If the grant cannot be read or the log cannot be written, the request is refused. The emails are best-effort: if one fails to send, access still opens and is still logged, and while an account is archived they are not sent at all.
The exceptions. While your account is complimentary (marked complimentary, or inside a trial period we set), People Purpose has standing access and visits are not logged; the complimentary mark clears by itself when a card subscription becomes active, a trial period ends on its date, and an account billed any other way is cleared by hand. A platform administrator who is a named member of your account needs no grant, and appears in your member list, where you can remove them unless they are the account's only owner. And our platform administration screen, used to set up and approve client accounts, works outside any grant: from it a platform administrator can see your company's name, settings and account flags and your list of logins with their email addresses, roles and last sign-in, and can invite a login at any role (including adding themselves, which makes them a named member), change a login's role, or revoke one. Those actions do not appear in your Support access log and do not email you. Nothing on that screen shows your people's results, notes or hiring files. Separately, a platform administrator can open the full report for any assessment, in any client account, from our own dashboard without a grant (name, company, DISC style and character traits); this is built for the free assessments taken on our public site, but it reads any assessment by identifier. Each such read is written to an internal log (administrator, assessment, account, time) before anything is returned, and a failed write refuses the read. That log is not shown in your Support access log and nothing is emailed; we will tell you what it holds for your account on request. At the database level, as the paragraph above explains, our server code can reach everything; these controls govern what the product lets us do, not what the database could return.
The old staging environment. Until 16 August 2026 we ran a staging site with its own separate database, and earlier versions of this addendum listed it as a safeguard. The staging site was shut down that day and nothing in the product uses its database. That database held copies of some client records, including client employees, and we have not yet confirmed that it has been deleted. [[CONFIRM THE STAGING DATABASE IS DELETED — ROD]]
Encryption of data at rest is whatever Supabase and Netlify provide by default. We have not configured or verified anything beyond that and we do not claim a specific standard. We do not run our own backups; whatever backup and point-in-time recovery exists is the provider's. [[CONFIRM BACKUP POSTURE — ROD]]
Personnel. One person operates the platform. Access to production credentials is limited to that person. There is no other staff member with access to your data today. If that changes, anyone with access will be under a written confidentiality obligation before they get it.
Inside your own account, access follows the role you give someone:
| Role | Reach |
|---|---|
| Employee | Their own record, matched to their own login email: their job description, course progress and task list; where you run weekly check-ins with them, their check-ins, Top 5, 1:1 agenda and the KPI marks given in their weekly 1:1; and a download of what is held about them. Their own DISC style, their two character traits and the version of their report about them always appear on their page; the parts of the report written for other people (how to work with, manage and write to them, and the working-with playbook) appear only once their manager or you switch that on for them, and the notes their manager files in their 1:1s only once their manager or you switch that on. Their page also shows their manager's DISC style (primary and secondary style, style mix, and the written tips for that style), never their manager's character traits or answers; their manager here is the person in the seat theirs reports to on the org chart, and a manager's own page tells them that the people in the seats reporting to theirs see their style. Someone on this role who sits above other people on the org chart can open those people's profile pages (name, title, job description and DISC style), and, for the people who report to them directly (the nearest filled seat above theirs), the DISC report page, which shows the style, not the character traits; one who runs a person's weekly 1:1 also reaches that person's check-ins, 1:1 agenda, tasks and meeting page, and, if they are that person's manager on the org chart (the nearest filled seat above theirs), that person's two sharing switches. |
| Viewer, sales, marketing | Every assessment in your account: name, email, company and DISC, plus the full narrative report, and the ability to generate a new one. If you are giving out a "read-only" role expecting it to be limited to a subset of people, it is not. Assign it accordingly. |
| HR, admin, owner | All of the above plus the whole hiring side: candidate records, resumes, AI reads, notes, interview transcripts, screening interview recordings, AI-suggested ratings, recommendation reports, reviews and the invitation tools. They can also remove a single uploaded resume file from a person's record. |
| Owner and admin only | Managing the team: archiving members and revoking logins. Deleting an assessment and the full delete of a member's data are switched off (section 17). |
The asymmetry between an employee and their manager, stated plainly. Two sharing switches, set one person at a time, decide part of what an employee sees: "Full DISC report" and "1:1 notes". The DISC switch only adds the parts of their report written for other people; the version about them is always on their page. Both start off, except where the person's own login already shows it: the DISC switch is always on for any login other than employee, and the notes switch is always on for an owner, admin or HR login, which can open every 1:1 record in your account, the person's own included. The person's manager on the org chart, whatever login that manager holds, or an owner, admin or HR login (including a certified partner firm person with administrator access) can turn either on or off, from the manager's list of direct reports or their list of the 1:1s they run, and each change is recorded with who made it and when. Whichever switches are on, the manager additionally sees, depending on their login, the employee's "how to manage me" preferences, the generated alignment read on how they sit against their role, the review ratings and notes from both sides, the full AI-written narrative report, and the transcript of any 1:1 that was recorded (unless the employee's own login is owner, admin or HR, which reads every 1:1 record, transcripts included). While the "1:1 notes" switch is off, the manager also sees the 1:1 notes and KPI-mark notes the employee does not; that never happens for an owner, admin or HR login, whose notes switch is always on. If you tell your team that Quadrant is a development tool, that is true, and this is the part you should tell them as well.
One report link is unauthenticated: a shareable report link is the assessment's own identifier, and anyone holding that link can open the scores, name, company and date without signing in. It is unguessable, but it is not access-controlled. Treat a shared report link as public and do not paste it anywhere you would not paste the report. The same caution applies to a recommendation report share link (section 9.6): it is signed and expires after 14 days, but until then anyone holding it can open the whole report without signing in.
When one of your employees or applicants asks to see, correct or delete what is held about them, it is your request to answer. PIPEDA gives you thirty days. We will help you meet that.
Our commitment. If you forward us a request, we will respond to you with what we hold about that person, in a readable form, within ten business days. If you instruct us to correct or delete a record, we will do it within ten business days and confirm in writing. If an individual contacts us directly about information that belongs to your account, we will not action it ourselves — we will tell them to contact you and let you know it happened.
How this actually works today, without varnish. Apart from the download described below, there is no self-service export and no automated request handling. Everything else is a person doing database queries by hand. Three things follow:
What does work automatically. Every status email to an applicant carries a one-click link to remove themselves from your pool, which suppresses further contact and stops any further email. Every role-invitation email carries a one-click unsubscribe and a standard list-unsubscribe header. Growth Program emails carry an opt-out. Marketing emails carry an unsubscribe that our senders check before sending, and which fails closed — if the check cannot be completed, the email is not sent. All of these are suppression, not deletion. Nothing is erased by clicking them, and the pages say so.
Our commitment to you. If we become aware of a breach of security safeguards involving your people's information, we will notify your account owner without undue delay and in any event within 72 hours of becoming aware. The notice will say what happened, when, which categories of information and roughly how many individuals are affected, what we have done, and what we recommend you do. If we do not have all of that at 72 hours, we will send what we have and follow up.
We will not notify your employees or applicants ourselves unless you ask us to in writing, or the law requires us to.
Your obligation, which we cannot discharge for you. Under PIPEDA section 10.1, if a breach involving information under your control creates a real risk of significant harm to an individual, you must report it to the Privacy Commissioner of Canada and notify the affected individuals, as soon as feasible. Under section 10.2 you must notify other organisations that may be able to reduce the risk. Under section 10.3 you must keep a record of every breach of security safeguards, whether or not it created a real risk of significant harm, and keep it for 24 months, and give it to the Commissioner on request. Failing to report or to keep records is an offence under the Act.
We keep our own record of every breach on the same basis, for the same period, and we will give you a copy of the entry for any incident that touched your data.
If you are a provincially regulated employer in Alberta, Alberta PIPA imposes its own duty to notify the Alberta Commissioner. British Columbia's rules differ. Your counsel should confirm which regime applies to you before you rely on this paragraph. [[COUNSEL TO VERIFY THE PROVINCIAL BREACH DUTIES]]
There is no general retention schedule. One category of record is deleted on age: recorded screening interview media, at 90 days, and sooner on close, rejection, hire, role fill or an expired screening deadline, described in section 9.4. The raw submission archive, described in section 6.2, does not have a deletion schedule yet; we clear it by hand. Everything else stays until somebody removes it. We are telling you this rather than printing a retention table we do not honour.
Deletion today is operator-initiated, immediate and permanent: there is no recycle bin and nothing to restore from. Treat every deletion below as final.
On 12 October 2026 the product's permanent deletes of a client account, a person, a candidate, a team member's data and a job were switched off; each now refuses and deletes nothing. What your staff can do instead keeps the record: dismiss an applicant, close a role, archive a team member (off the roster and the bill, history kept, restorable), or revoke a login, which removes the membership and course state for your account and keeps their results. Archiving a client account deletes nothing and is meant to stop the product's emails and texts to it and its people; that block can take a few minutes to apply, catches some messages (such as a new login invitation or a password reset) only if the address is on the account's records, and does not cover payment receipts from our card processor. The same switch-off, later that day, covered deleting an assessment result or an interview session, merging duplicate records and un-rejecting an applicant. The permanent deletions that remain are small: an owner, admin or HR user can remove a single resume file; a saved Read-a-person result can be deleted by whoever saved it or by an owner or admin; and working items such as an empty org-chart seat, a team, or a goal nobody has agreed yet can be removed.
What no code path deletes, and you should know it:
Commitment. We will agree a written retention schedule with you if you want one, and we will apply it by hand until it is automated. If you tell us your own schedule — for example, applicant records for one year after a role closes — say so in writing and we will run to it.
When your subscription ends, whichever comes first:
Two honest notes about the mechanics. The platform function that deleted a whole client account was switched off on 12 October 2026, so the deletion above is done by hand, record-set by record-set, and confirmed in writing. And apart from screening interview recordings, which are purged on their own schedule, nothing in the product deletes a client's files from storage in bulk, so file deletion at termination is a manual step too.
Copies held by sub-processors follow their own deletion timelines. Email delivery records at our email provider and platform logs at our host are not under our direct control and will age out on their schedules, not ours.
You are accountable for information you transfer to us, so you are entitled to satisfy yourself that we handle it properly. This is written to be proportionate to what we are: one person, not an enterprise vendor with an audit team.
We do not have a SOC 2 report, a penetration test report or a third-party audit to hand you. When we do, this section will say so.
Everything below is unresolved. It is collected here so that nothing in this document quietly depends on a fact nobody has checked.
privacy@disc-quadrant.com and jobs@disc-quadrant.com are monitored mailboxes.People Purpose Corporation
7 Fox Run, Kleefeld MB, R0A 0V2, Canada
Rod Penner, rod@people-purpose.com
Privacy requests: privacy@disc-quadrant.com
See also: how the assessment works and how to use it responsibly, and the assessment privacy notice written for the individual taking it.