1. Scope and privacy roles
This notice applies when you visit the Evidize website, communicate with us, use an account, connect an authorized Microsoft 365 environment, or participate in a hiring workflow that uses Evidize.
For candidate, application, interview, and screening information submitted or configured by a customer, the hiring organization generally decides why and how the information is used and acts as the controller or business. Evidize generally processes that information for the organization as its processor or service provider. The exact role depends on the processing context, the customer agreement, and applicable law.
Evidize may act as a controller for information used to operate its own website, accounts, security, support, and business relationships. If an organization invited you to an interview or assessment, its privacy notice may provide additional information and should be read alongside this notice.
2. Information we handle
Public website and commercial inquiries
The website’s location feature sends a request to Evidize’s public location endpoint. That endpoint receives the requesting IP address and uses a local location database to return an approximate city, region, and country for limited page personalization. It does not use browser GPS coordinates in the current website workflow.
The current marketing-site bundle does not set its own cookies or initialize an advertising or analytics SDK. The
plans and features pages do generate limited interaction events, including the event name, page, selected audience
or plan, interface location, feature section or product-screen key, FAQ topic, input method, or form-field label.
They dispatch those events in the browser and, if the deployment provides a pre-existing
dataLayer, push the same metadata to it. Those events do not include the name, email, company, or
message typed into the inquiry form. The current source does not identify a recipient for a deployment-provided dataLayer.
Public pages use the visitor’s locally available system typefaces and do not request a web font from a third-party font service.
Service and API requests can create technical records such as IP address, user agent, request method, path and complete query string, request or correlation identifiers, response status, duration, and error details.
The plans inquiry form prepares an email draft on the visitor’s device. The entered name, work email, company, hiring model, monthly interview range, recruiting-firm client-account range when applicable, plan interest, and message are not sent by that form until the visitor chooses to send the email. If a visitor follows a configured scheduling link, the scheduler receives the information the visitor supplies to it.
Accounts, organizations, and authentication
Account and organization records can include name, work email, organization membership, role and permissions, Microsoft Entra object and tenant identifiers, password hashes, authentication-method and multi-factor state, sign-in and password-change timestamps, account status, organization name, subdomain, address and contact information, consent and sender settings, plan or subscription status, feature limits, usage counters, organization logos and backgrounds, and user avatar images. Login records can include IP address, raw and parsed user agent, browser, operating system, device type, authentication method, failure reason, and the email used in a failed attempt. Current account records include plan and billing-period configuration but no payment-card field or payment-processor integration.
The service uses a tenant-routing cookie containing the organization subdomain and browser storage for sign-in and workflow state. The tenant-routing cookie defaults to a maximum age of 30 days, and deployment configuration can change that duration. Current portals ordinarily write service and candidate access tokens to session storage; shared compatibility code can read and clear legacy local-storage copies.
Browser-local workflow records can include the selected organization and preferences; interview-generator drafts containing candidate name and email, meeting URL and time, requisition, hiring-manager, client, and job-description context; recruiter-entered resume notes; and a candidate-download acknowledgement marker. These records remain on the device unless the workflow or user clears them, browser storage is cleared, or the limited draft-expiry behavior described below applies.
Candidate, application, and interview records
Depending on the customer workflow, we handle candidate name, email, phone number, address or location, public professional and portfolio links, cover letter, application and screener answers, resume files and extracted resume text, source, referral and campaign parameters, locale, work history, education, skills, certifications, work authorization, relocation, travel or work-arrangement preferences, and talent-alert preferences. Candidate records can also include a customer-uploaded avatar image. Candidates may choose to submit voluntary self-identification information such as gender identity, ethnicity, race, veteran status, and disability status. The product stores that voluntary information separately from the ordinary application record and exposes aggregate compliance summaries only to eligible organization or platform administrators. The current candidate-profile, fit, and application-quality workflows do not use those voluntary fields.
Public-application anti-abuse and duplicate-submission controls process the remote IP address and user agent and derive SHA-256 IP, request, resume, and application fingerprints. The stored rate-limit and idempotency values are hashes or fingerprints, not readable copies of the IP address or resume content.
Interview and assessment records can include recruiter, hiring manager, agency client and requisition context; meeting links and scheduled times; session, short-link and candidate access state; link access counts; download time, IP address, user agent and acknowledgement; monitoring and meeting-access state; scorecards, ratings and comments; evidence reports; application and hiring stages; recruiter or customer notes; and the customer user’s recorded decision, reason, and timestamp.
Audit, communications, and diagnostic records
We store feature activity, access and authentication events, consent evidence, security detections, rate-limit identifiers, audit history, and operational health records. Assistant evaluation records can include the user’s query, resolved command, match source and confidence, missing parameters, clarification text, feedback, and a resolution identifier. Non-marketing email records can include a recipient address or account/application reference, organization, event and aggregate revision, immutable template version and locale, sender identity, approved template variables such as a recipient display name, job or organization label, and event time, transport route, status, attempts, safe provider-evidence classification, correlation identifiers, timestamps, suppression state, and retention class. The email delivery ledger does not store the completed message body, raw action token, protected-link target, raw meeting URL, password, MFA material, or organization email credential.
Depending on the event, an audit or diagnostic record can contain candidate or user names and email addresses, session and application identifiers, short codes, complete request paths and queries, error details, and other event metadata. Signed resume and avatar URLs can place a short-lived access token in the query string; deployment logging and redaction controls must prevent those credentials from being retained or exposed. Transactional email does not use a logging fallback, and raw message bodies, action links, provider responses, and credentials are prohibited from application logs, traces, audit metadata, exports, and support tooling.
3. Microsoft 365 and Outlook
Microsoft Entra sign-in uses the openid, profile, and email identity scopes. Evidize receives identity claims such as object ID, tenant ID, email or user principal name, nonce, and available name claims, and uses them to authenticate or synchronize the account. The main portal sign-in does not request Microsoft Graph access. The browser sends the Microsoft ID token to Evidize for verification. The backend derives and temporarily retains replay-protection values, including the nonce, object and tenant identifiers, and a SHA-256 token fingerprint, until the token expires or a one-hour fallback period ends; it does not put the raw token in that replay cache.
Microsoft authentication libraries use local storage for account and token-cache artifacts and can retain ID-, access-, or refresh-token artifacts returned by Microsoft. The bundled fallback authentication dialog also enables an authentication-state cookie. These browser-side artifacts are distinct from Evidize’s current server implementation, which does not persist a Microsoft Graph refresh token.
When an authorized user opens the Outlook workflow, the add-in can read fields from the currently open message or appointment under Outlook’s ReadWriteItem permission. The current workflow reads required and optional attendee names and email addresses, start and end times, location, and body text or HTML to identify an external candidate and meeting URL. The full item body is processed in the browser for link detection; the backend receives the selected candidate, schedule, detected meeting URL, requisition, hiring-manager, client, and session-status information rather than the full item body.
The user can ask Evidize to insert generated invitation HTML into the currently open item. The user controls whether to save or send it. The current workflow does not use Microsoft Graph to create or send an event and does not access attachments, contacts, files, or general mailbox, calendar, or browsing history. A user can separately select and upload a resume through the Evidize workflow; the add-in does not read that file from an Outlook attachment.
A separately bundled fallback can exchange a delegated access_as_user assertion for User.Read and request the signed-in profile at Microsoft Graph’s /me endpoint by default. The delegated scope and fallback endpoint path or query are deployment-configurable. The default request does not select a limited set of profile fields, and the returned JSON is passed transiently back to the add-in. It is delegated, not application-level, access.
Evidize separately uses a non-interactive Microsoft Graph workload identity to send platform-owned non-marketing account, security, access, operational, and approved fallback communications from dedicated service mailboxes. Exchange role assignments restrict that identity to those mailboxes. The service creates a message draft, submits that draft, and can use Sent Items reconciliation, non-delivery reports, and a separate Message Trace identity to classify later evidence. Microsoft accepting a Graph request for processing is not proof of Exchange delivery, inbox placement, or reading. Message Trace evidence also does not establish inbox placement or reading.
When an organization connects Microsoft delegated SMTP OAuth for organization-owned candidate or internal communications, the refresh credential is stored as a versioned write-only secret in Evidize's dedicated secret vault. A short-lived access token is obtained and used only in worker memory. This organization connection is separate from portal sign-in, the Outlook add-in, and the platform Graph mail identity.
Outlook remains responsible for sending calendar invitations and changes for meetings created in the Outlook workflow. Evidize does not send a competing calendar invitation for those meetings, although it can send a separately classified protected-link setup reminder. Meetings created by the platform use one calendar identity whose revision changes for rescheduling or cancellation.
If the deployment supplies a browser telemetry object, the Outlook workflow can send event metadata such as event name, recruiter-client identifier, internal or external context, source, selection, and success or failure. The current source does not initialize or identify the recipient for that deployment-provided telemetry object.
4. Companion monitoring: metadata and content
During an active Windows or macOS screening session, the shipped companion software inventories running applications and processes. It sends application or process name, process identifier, raw executable path, normalized path and deterministic path fingerprint, process lifecycle timestamps and state, and, on Windows, the process-account username. The service compares those records with configured tool signatures and stores derived match labels and detections. Raw paths are not replaced by the fingerprints.
The network collector observes TCP connection metadata, including protocol and local and remote IP addresses and ports. The backend normalizes and stores remote endpoint information and can derive tool or category matches. The shipped collector does not inspect packet contents, capture transmitted files, resolve browsing history, or report actual upload or download byte totals.
The companion sends display count, display index and dimensions, and primary or built-in display state. It does not capture screenshots, screen pixels, or screen content. It also sends device and operational information such as hostname, operating system, agent version, installation scope, administrative or elevated status, capability flags, CPU and memory use, queue depth, upload latency, uptime, degraded state, and health status. The backend records heartbeat receipt and last-activity timestamps and retains the session IP address and key heartbeat fields such as hostname, operating system, version, and administrative status. The currently shipped collectors do not send display serial numbers, vendor or model values, or virtual-machine status or vendor.
Clipboard checks
The Windows and macOS clipboard collectors locally read clipboard text to calculate its character length. On Windows, the collector can also locally read copied file names to total their lengths. The shipped event payload does not include that text, those file names, or a content preview.
The clipboard event queued for upload contains metadata such as content type or MIME type, length, timestamp, blocked state, and a SHA-256 fingerprint derived from type, length, and clipboard sequence or format information. That value is a metadata fingerprint, not a hash of the clipboard text. Although the backend schema has fields capable of storing a preview, source application, window title, and policy reason, the currently shipped collectors do not populate those fields. They set the blocked value to false and do not block clipboard content.
Browser and extension activity
The currently shipped companion registers process, network, display, and clipboard collectors. It does not register a browser or extension collector and does not currently send installed extension identifiers or names, browser URLs, tab or window titles, navigation history, browsing history, active-tab state, or page content. Backend fields that can accept browser-event data do not establish current collection without an active producer.
Local queueing
The companion normally writes collector telemetry batches to a local JSON upload queue before attempting delivery. Heartbeats and other control messages do not use that telemetry queue, and an upload can proceed if queue persistence fails. Queued batches are removed after successful upload; failed uploads are retried, and invalid queue files can be quarantined. The current companion code does not define a general cleanup period for failed or quarantined queue files. Companion logs roll daily and the current configuration retains five local files, each capped at 10 MB.
5. AI-generated information and automated processing
Resume, candidate, and requisition analysis
When the applicable AI features are configured, Evidize sends information to Azure AI Foundry. Prompts can include candidate identity or label, up to 20,000 characters of extracted resume text, a structured candidate profile, requisition and screener context, job-description text, and requisition criteria. Authorized-user assistant queries and context used to generate scorecards or resolve commands can also be sent.
The service stores generated and inferred information such as structured candidate profiles, resume summaries, conversation openers, seniority and consistency assessments, employment history and gaps, skills and evidence, baseline and job-fit assessments, strengths, concerns, follow-up prompts, scorecards, overall and component scores, confidence values, recommendations, quality bands, knockout reasons, evidence summaries, and candidate rediscovery matches. Candidate lists can be sorted or summarized using those quality and fit results. Some quality scores, knockout flags, sort orders, and rankings are calculated by application rules rather than generated by an AI model.
AI request logging stores the full serialized request, full provider response payload and response text, error information, organization, user or session context when available, model and agent identifiers, request identifiers, latency, and token counts. Only a separate convenience preview is truncated.
Screening score, verdict, and meeting access
Evidize automatically derives evidence labels, a 0–100 screening score, and clear, warn, or detected verdict states from available stored process and network detections, display information, and clipboard event frequency. Non-empty clipboard metadata events from the shipped agent match the active ingestion contract and are persisted; their event rate can contribute to the configured clipboard component of the screening score. An empty clipboard batch stores no event row but updates a receipt timestamp used as a coverage handshake. Process and network remain the required coverage sensors; clipboard telemetry is not required for release. Detection and coverage rules can also flag unaccepted required consent or high-confidence process or network matches.
The service can automatically withhold or release a protected meeting link. The link is withheld unless required consent is acknowledged, required telemetry is available, the candidate gate is ready, coverage is sufficient, and the screening verdict is clear. This access control can operate without a customer user first reviewing the individual result.
AI-generated or rules-derived profiles, scores, knockout flags, rankings, fit assessments, evidence, and next-step recommendations are decision support. Authenticated customer users control application-stage changes and record hiring or assessment decisions and notes. Evidize does not make the customer’s final employment decision.
6. Candidate notice, consent, and controls
Before the companion download and protected meeting workflow, the candidate portal can present a required platform consent notice and, when the organization or recruiter configuration requires it, an organization-specific notice. A required notice is presented in a non-dismissible, scroll-gated acknowledgement dialog.
Monitoring consent is recorded once for a session. A retry returns the existing approval, and changing the configured notice text or version does not automatically require that session to acknowledge it again.
Monitoring-consent evidence stores a snapshot of candidate name and email, acknowledgement time, IP address, user agent, policy version, message hash, full message snapshot, short code, and related metadata. The current compliance workbook exports the approval and session identifiers, candidate name and email, acknowledgement time, IP address, policy version, message hash, short code, related metadata, and full message snapshot; it does not export the stored user agent.
The public job-application form separately requires the applicant to acknowledge the application notice before submission. The application record stores whether that acknowledgement was required and accepted and the notice version. This application notice is separate from the companion-monitoring consent described above.
The current candidate portal does not provide a self-service consent withdrawal, revocation, appeal, accommodation, or alternative-assessment control. Consent approval records are treated as immutable evidence in the product and cannot be deleted through the consent administration endpoints. A candidate seeking withdrawal, human review, an appeal, an accommodation, or an alternative process should contact the organization conducting the hiring process.
7. How information is used
We use information to:
- provide, maintain, and support accounts, applications, interviews, and assessments;
- authenticate users and enforce tenant, role, assignment, and feature permissions;
- create short links, invitations, candidate sessions, and protected meeting workflows;
- receive and analyze the companion signals described above;
- detect configured indicators of disallowed tools or suspicious activity;
- generate profiles, assessments, scores, rankings, evidence, alerts, and scorecards;
- automatically gate protected meeting access as described above;
- send non-marketing account, security, application, human-approved stage, and interview communications;
- support customer review, exports, audit, compliance, and recordkeeping workflows;
- prevent abuse, apply rate limits, verify public-application CAPTCHA responses, and investigate failures;
- operate customer relationships and respond to communications; and
- diagnose errors and monitor service and companion health.
The current product code does not use candidate screening information to serve third-party advertising.
9. Retention, deletion, and exports
Retention depends on the type of information, customer configuration and instructions, contractual requirements, account lifecycle, security needs, and applicable law. Customer agreements or configured policies may establish additional requirements.
The ATS has separate organization-configurable retention windows for applications, resume assets and extracted text, and certain ATS AI results. Those settings do not mean that every linked or derived record is erased when a period ends. The current deployment does not schedule the ATS purge. The current authorized purge command does not delete every type of linked application record, and remaining linked rows can prevent an application hard-delete step from completing. A configured window therefore does not guarantee completed deletion. Separate lifecycles apply to candidate profiles, job-fit assessments, notes, rediscovery records, consent evidence, audit records, and AI request and response logs.
Many customer-admin deletion actions are soft deletions: the record is removed from ordinary active views but remains stored with a deletion timestamp. Authorized platform operations can hard-delete some account, candidate, session, asset, and telemetry records. When retained consent or audit evidence prevents physical session deletion, the underlying session record is soft-deleted without scrubbing the remaining fields on that record, which can include candidate identity, interview links and times, customer decisions and notes, device and network identifiers, report fields, and download acknowledgements. We do not describe a soft-deleted record as erased.
A platform-admin telemetry purge physically deletes the current server-side process, display, clipboard, network, and browser telemetry rows and resets related heartbeat and report fields. It does not remove pending upload-queue files on a candidate device or customer-exported copies. Screening telemetry otherwise has no code-defined automatic retention schedule.
Consent approvals and certain compliance audit records are treated as immutable evidence. AI request and response logs are not linked into every application or candidate-profile deletion cascade and may remain after those records are deleted. Server application, AI, and general diagnostic logs do not share one code-defined retention period; the companion’s separate local log rotation is described above.
Transactional-email retention has several separate domains. Evidize controls retention of its recipient-specific delivery ledger, sanitized attempts and provider events, template versions, and suppressions within configured bounds. Evidize's Exchange Sent Items, non-delivery mailbox content, and Message Trace data follow the separately configured Microsoft 365 retention policy. Copies, queues, logs, sent items, and backups held by an organization-selected SMTP provider follow that organization and provider's settings and terms. Secret-vault versions and ordinary database backups follow their own rotation, soft-delete, purge-protection, and backup-retention controls. Deleting an application ledger record does not by itself establish deletion from those separate systems.
Interview-generator drafts are removed as expired when loaded more than 24 hours after they were saved; this is not a timed background purge. The current code defines no automatic expiry for recruiter resume notes or candidate-download markers stored in local storage. Talent-alert unsubscribe deactivates and soft-deletes the subscription record rather than immediately erasing it.
Recruiter and compliance exports can include candidate identity and contact information, application and resume metadata, candidate profiles, AI analysis and detections, scorecards, decisions, consent evidence, and audit records. Export artifacts can be stored in the configured storage backend before download. A displayed expiry or configured retention value is not a representation that every downloaded copy or related record is automatically deleted; customer-held copies follow the customer’s retention practices.
10. Access, tenant separation, and security
The application uses logical tenant scoping, role and assignment checks, password hashing, hashed one-time authentication tokens, bearer-token validation, and audit events. Ordinary customer users are limited by organization and assignment rules; organization administrators have broader access within their organization; and eligible compliance administrators can view or export designated records.
Platform administrators can access the cross-tenant categories described above and can perform platform administration or impersonation. Accordingly, information is not visible only to the customer that submitted it. Specific actions—including candidate-profile or session-telemetry access, deletion, and impersonation—generate audit events. The code does not establish that every cross-tenant read is audited or determine which personnel are granted the platform-administrator role.
No method of storage or transmission is completely secure. Customers also remain responsible for their account security, authorized-user access, Microsoft 365 tenant configuration, and lawful service configuration.
11. Legal bases
Where data-protection law requires a legal basis, the applicable basis depends on the context. It may include performance of a contract, steps requested before entering a contract, legitimate interests in providing and securing the service, compliance with a legal obligation, or consent where consent is required.
When Evidize acts as a processor, the customer determines the applicable legal basis for its processing. Customers are responsible for providing required notices, obtaining required consents, and configuring the service consistently with applicable employment, privacy, accessibility, and monitoring laws.
12. Your privacy rights and product controls
Depending on your location and relationship with Evidize, you may have rights to request access, correction, deletion, restriction, portability, or objection, and to withdraw consent where processing relies on consent. You may also have the right to complain to a data-protection authority.
If your information was provided by a prospective employer, recruiting firm, or other customer, contact that organization first. Because it generally controls the information, we may refer your request to it and support its verified instructions. We may need to verify your identity and tenant before acting, and a completed administrative action can generate an audit record.
Product administrators can correct certain account, application, candidate, and session fields; create authorized exports; soft-delete records; and, for platform administrators, invoke certain hard-delete or telemetry-purge operations. The candidate portal does not provide a self-service copy, correction, deletion, portability, consent-revocation, or appeal workflow, and customer users do not have a dedicated self-service privacy-request or account-closure workflow. Talent-alert subscribers can use the secure management link to update preferences or unsubscribe, although unsubscribe is the soft-deletion behavior described above. A rights request may therefore require a verified customer instruction or an authorized operational process, and retained consent, audit, security, or deletion records may remain where applicable.
13. Changes and contact
We may update this notice to reflect product, legal, or operational changes. We will post the revised notice here and update the effective date. Material changes may also be communicated through the service or customer channels where appropriate.
Privacy questions and requests may be sent to sales@evidize.com.