Developer Security

Document type: Internal Standard — Available to End Users
Version: 0.1
Owner: Harshil Patel, Chief Technology Officer
Co-owner: Pat Roscio, Chief Operating Officer
Applies to: All Scholera engineers, contractors, and any party contributing code or receiving system access
Review cadence: Semiannual, or upon material change to architecture, tooling, or regulatory obligations
Contact: proscio@scholera-inc.com

This standard defines the security requirements that govern how software is built and operated at Scholera. It exists because our platform holds student education records for institutions that are legally accountable for those records. Every engineering decision we make is made on their behalf and under their liability.

This document is deliberately prescriptive. Where a requirement is stated as a rule, it is a rule, not a recommendation. Where a control is aspirational rather than implemented, it appears in Section 20 with a date rather than being described in the present tense.

This standard applies to:

All Scholera employees and founders who write, review, deploy, or operate code
All contractors, agencies, and individual freelancers contributing to any Scholera codebase
All AI coding agents operating under a Scholera engineer's direction, where the supervising engineer holds full accountability for the output
All third party service providers whose systems process, store, or transmit Scholera data, as specified in Section 18
All environments: production, staging, development, and local

Document	Relationship
Privacy Policy	External commitments to users and institutions. This standard implements the technical controls those commitments depend on.
Privacy Management Program	Governs personal data handling, rights requests, vendor privacy assessment, and non-compliance response. This standard governs the code and systems that process that data.
Institutional agreements and DPAs	Contractual obligations. Where an institutional agreement imposes a stricter requirement than this standard, the agreement governs for that institution.

Where documents conflict, the stricter requirement applies.

The Chief Technology Officer owns this standard. Exceptions require written approval from the CTO and the Chief Operating Officer, must specify a scope, a compensating control, and an expiry date, and are recorded in the Exception Log maintained under the Privacy Management Program. There are no verbal exceptions and no permanent exceptions.

Failure to follow this standard is a security incident, not a style disagreement. Handling follows Section 17 and the non-compliance framework in Section 13 of the Privacy Management Program. Good faith errors reported promptly are treated as process failures. Concealment is treated as serious misconduct.

These principles resolve situations this document does not explicitly cover.

Assume the data is not ours. Student records belong to students and to the institutions that hold them. We are custodians with a narrow, revocable mandate. Design as though every record has a name attached, because it does.

Prefer controls that make violations impossible over controls that prohibit them. A permission enforced by a database policy is stronger than a permission enforced by a code path, which is stronger than a permission enforced by a rule in a document.

Default deny. New endpoints, new data, new roles, and new integrations start closed and open only by explicit decision.

Minimize blast radius. Assume any single component will be compromised. Design so that compromise of one does not yield the rest.

Log the security relevant, never the sensitive. Auditability and confidentiality are not in tension if you are deliberate about what goes into a log line.

Small surface beats hardened surface. The most secure dependency is the one not installed. The most secure endpoint is the one not exposed. The most secure data is the data not collected.

Be honest about posture. Do not describe a planned control as an existing one, internally or externally. Section 20 exists so that gaps have dates instead of euphemisms.

Role	Holder	Security Responsibilities
Standard Owner	Harshil Patel, CTO	Owns this document. Approves exceptions. Owns production access provisioning and review, dependency and vulnerability management, encryption and key handling, deployment authorization.
Frontend Security Lead	Kevin Doshi, CEO	Client side security: output encoding, CSP, dependency hygiene in the frontend tree, secure handling of tokens in the browser, consent and notice surfaces.
Privacy Program Owner	Pat Roscio, COO	Institutional and regulatory notification, privacy non-compliance handling, vendor contractual review, institutional security questionnaire responses.
Contributing Engineer	All engineers and contractors	Compliance with this standard for all code authored, reviewed, or deployed. Reporting suspected issues within 24 hours.
Reviewer	Any engineer reviewing a pull request	Verifying the security requirements in Section 6 before approving. A review approval is an assertion that the reviewer checked.

No engineer reviews and approves their own change to production.

Every piece of data in the system belongs to one of four classes. Classification determines handling requirements throughout this standard.

Class	Definition	Examples	Handling
Restricted	Personal data whose exposure would harm an individual or breach a legal obligation	Student names, institutional emails, enrollment records, assessment submissions, AI interaction content, uploaded course materials	Encrypted at rest and in transit. Access logged. Never in logs, error messages, analytics, URLs, or non-production environments. Never in prompts beyond documented necessity.
Internal	Operational data that is not personal but not public	Encrypted user identifiers, system configuration, aggregate usage metrics, internal architecture detail	Encrypted at rest and in transit. Access role scoped. Not shared externally without approval.
Secret	Credentials and key material	API keys, database credentials, service account keys, signing keys, session secrets	Never in source control, logs, error messages, screenshots, tickets, or chat. Managed per Section 8.
Public	Content intended for public consumption	Marketing copy, published documentation, public API schemas	No restriction.

When classification is ambiguous, treat the data as one class more restrictive than your instinct.

Restricted data must never appear in: URL paths or query parameters, log output, error messages returned to a client, analytics or telemetry payloads, non-production databases, local development environments, third party services not listed in the subprocessor inventory, LLM prompts beyond what Section 10 explicitly permits, or any AI coding assistant context window.

Security is applied at every phase, not appended at the end.

Before implementation begins on any feature that touches Restricted data, authentication, authorization, AI inference, or a third party integration, the responsible engineer produces a short design note covering:

What data the feature touches and its classification
Which roles may access it and how that is enforced
Whether the feature introduces a new data element, requiring a Data Inventory update
Whether the feature requires a Data Privacy Impact Assessment under Section 8 of the Privacy Management Program
What could go wrong, and what control prevents each failure

The design note need not be long. It needs to exist and be reviewed.

For features involving authentication, authorization, AI inference, file upload, or external data ingress, the design note includes a lightweight threat model addressing at minimum:

Spoofing: can an actor claim an identity they do not hold?
Tampering: can data be modified in transit or at rest by an unauthorized party?
Repudiation: is there an audit record sufficient to establish what happened?
Information disclosure: can a user reach data outside their role scope? Can an inference reveal what a direct query would not?
Denial of service: can a single actor consume disproportionate resources?
Elevation of privilege: can a user assume a higher role, or can the LLM act with more authority than the requesting user holds?

Code is written to the requirements in Sections 6 through 12.

Every change is reviewed by an engineer other than the author, against the checklist in Appendix A. Review is a security control, not a formality.

Changes are validated in staging before promotion to production, against the checklist in Appendix B.

Deployment is authorized by the CTO per Section 13.

Monitoring per Section 14. Any anomaly is treated per Section 17 until proven benign.

Validate all input at the trust boundary, on the server, against an explicit allowlist schema. Client side validation is a usability feature and provides no security guarantee.
Reject invalid input. Do not sanitize and proceed, because silent coercion produces states no one designed for.
Enforce explicit length, type, range, and format constraints on every field. Unbounded input is a denial of service vector and a storage cost.
Validate file uploads by content inspection, not by extension or client supplied MIME type. Enforce a maximum size. Store uploads outside the web root and serve through an authorization checked handler, never by direct path.

Encode output contextually at the point of rendering: HTML body, HTML attribute, JavaScript, URL, and CSS contexts each require different encoding.
Never construct SQL by string concatenation or template interpolation. Use parameterized queries or the query builder exclusively. This applies to internal tooling and one off scripts as strictly as to production code paths.
dangerouslySetInnerHTML and equivalents are prohibited without CTO approval and a documented sanitization step using a maintained sanitizer library.
Never pass user input to eval, Function, setTimeout with a string argument, or any dynamic code execution primitive.
Never construct shell commands from user input. Where a subprocess is unavoidable, use an argument array form and never a shell string.

Errors returned to clients are generic. Detail goes to server logs with a correlation identifier the client can quote to support.
Never expose stack traces, database errors, file paths, dependency versions, or internal hostnames to a client.
Fail closed. An error in an authorization check denies access. A catch block that swallows an exception and continues is prohibited in any code path that gates access to data.
Authentication failures return an identical response and take a comparable time regardless of whether the account exists, to prevent account enumeration.

No secrets in source, including in comments, test fixtures, seed data, configuration defaults, or commit history.
No Restricted data in test fixtures, seed data, or example payloads.
No commented out code containing credentials or internal endpoints.
No debug endpoints, verbose error modes, or diagnostic routes reachable in production.
No custom cryptography. Use vetted, maintained libraries and standard algorithms per Section 9.
No disabling of TLS verification, certificate pinning, or security middleware, including temporarily during local development in a way that could be committed.

Scholera engineers use AI coding assistants. The supervising engineer holds full accountability for every line produced.

Never paste Restricted data, Secret data, or production configuration into an AI assistant context.
Never paste proprietary architecture detail into a consumer tier assistant without confirming the provider's data retention and training terms.
Review generated code against this standard before committing. Generated code frequently contains string interpolated queries, missing authorization checks, permissive CORS configuration, and outdated dependency versions.
Generated code is subject to the same peer review requirement as hand written code. "The model wrote it" is not a review.

End user authentication is delegated to the connected identity provider through Google OAuth 2.0. Scholera does not issue or store end user passwords, which removes password storage, rotation, complexity enforcement, and reuse from our risk surface entirely.
Identity provider assertions are validated on every request. Signature, issuer, audience, and expiry are verified. A token is never trusted on the basis of prior validation alone.
Session tokens are stored in HttpOnly, Secure, SameSite cookies. Tokens are never placed in localStorage, sessionStorage, URL parameters, or any client readable store.
Sessions expire after a defined idle period and a defined absolute maximum. Session identifiers are regenerated on privilege change.
Administrative accounts require multifactor authentication. See Section 20 for current enforcement status and target date.

Authorization is enforced on the server for every request. A hidden UI element is not an access control.
Every data access enforces both role and tenant scope. Role alone is insufficient: an instructor at one institution must not reach a course at another, and the check must be structural rather than a conditional an engineer can forget to write.
Prefer database enforced row level policies over application layer checks where the data store supports it, so that a missing check in a new code path fails closed rather than exposing data.
Object level authorization is verified on every access by identifier. Accepting an identifier from the client and returning the corresponding record without checking the requester's entitlement to it is the most common and most damaging web vulnerability class, and it is prohibited absolutely.
Privilege escalation paths are explicitly enumerated in the design note for any feature that changes a user's role or entitlement.

Role	Scope	Permitted Access
Student	Own records within enrolled courses	Own interaction history, own submissions, instructor published course content
Instructor	Own courses	Enrolled student activity within that course, course content management, AI usage indicators for review
Institutional Administrator	Own institution	User provisioning, role assignment, platform configuration, audit log requests
Scholera Engineer	As provisioned per Section 15	Production access only with documented justification

No role may be granted access beyond this table without a design note, CTO approval, and a Data Inventory update.

All secrets are stored in a managed secret store or the platform's encrypted environment variable facility. Never in source control, never in a shared document, never in chat, never in a ticket.
.env files are listed in .gitignore before the first commit of any new repository or service. A repository is not created without this.
Automated secret scanning runs against the repository and the commit history. See Section 20 for status.
Secrets are scoped to the narrowest function and environment that requires them. Production and non-production environments never share a secret.
Rotation is required immediately upon: suspected exposure, commit to source control regardless of whether the commit was pushed, departure of any individual with access, and compromise of any system where the secret was used. Rotation on a routine schedule follows Section 20.
A secret committed to source control is treated as compromised even if the commit is reverted, because history is recoverable. Revert is not remediation. Rotation is remediation.
Exposure of any secret is reported to the CTO immediately and handled per Section 17.

Purpose	Requirement
Data in transit	TLS 1.2 minimum, TLS 1.3 preferred. HTTPS enforced on all endpoints with HSTS. No mixed content.
Data at rest	AES 256
Password storage	Not applicable. Scholera does not store end user passwords.
Hashing for integrity	SHA 256 or stronger. MD5 and SHA 1 are prohibited for any security purpose.
Randomness	Cryptographically secure random sources only. `Math.random()` is prohibited for any security relevant value including tokens, identifiers, and nonces.
Key material	Managed per Section 8. Never derived from a hardcoded value or a predictable input.

Scholera pseudonymizes user identifiers in interaction logging. Log records reference an encrypted identifier rather than raw personal data, so a log export does not constitute a disclosure of identity absent the decryption control.

Requirements:

The decryption control is held separately from the log store and is accessible only to personnel with production access under Section 15.
The mapping is never written into the log store itself, into analytics, or into any system that receives log data.
Any change to the identifier scheme requires CTO approval and an assessment of whether historical logs remain correctly attributable.

Internal service to service communication is encrypted.
Certificate validation is never disabled.
Deprecated protocol versions and cipher suites are disabled at the edge.

Scholera's core product is AI driven, which introduces failure modes that conventional application security practice does not address. These requirements are as binding as any other section.

The model has no direct access to the database, to institutional systems, or to any administrative function. All data reaches the model through an application layer that has already performed authorization.
The model has no access to the open internet.
The model operates strictly within the retrieval scope defined by the requesting user's role and course context. A student's query cannot retrieve content from a course they are not enrolled in, and this is enforced at retrieval time by a scoped query, not by prompt instruction.
Model output never directly triggers a state change. An output that would affect a grade, a record, or a student's standing is surfaced to a human for decision. See Section 10.5.

Prompts are constructed server side from templated components. User input is never concatenated into a system instruction position.
Restricted data enters a prompt only where documented as necessary in the Data Inventory. Where a pseudonymous reference suffices, use it.
The retrieval context passed to the model is scoped by an authorization checked query executed before prompt assembly. Retrieval scope is never determined by anything the model produces.
Prompt templates are stored in source control and reviewed like code. A prompt change that alters what data the model receives or what actions it may recommend is a security relevant change and requires review on that basis.

Treat all content the model reads as untrusted input, including instructor uploaded course materials. A PDF uploaded to a course is user supplied content that will be read by the model, and it can contain text directed at the model.

Requirements:

Model output is never executed, never used to construct a query, and never used to determine an authorization decision.
Model output rendered in the UI is treated as untrusted and encoded accordingly. A model can be induced to emit markup.
Retrieval scope, tool availability, and role are determined before inference and cannot be altered by anything appearing in retrieved content or user input.
Where the model produces a structured output consumed by application logic, parse and validate it against a strict schema and reject anything nonconforming. Never trust the shape.

Every request enforces a token cap. Caps are configurable per contract and per pilot.
Each user input maps to a bounded, defined inference operation. Recursive, open ended, or self extending model call chains are prohibited.
Rate limiting is applied per user and per institution.
Anomalous consumption triggers alerting per Section 14.

The following require human decision and may never be automated:

Any grade or assessment outcome
Any academic integrity determination
Any action affecting a student's standing or record
Any disclosure of student data to a party who did not already hold access

Model output informs these decisions. It does not make them. Any proposed feature that would automate a decision in this list requires a Data Privacy Impact Assessment and founder level approval before design begins.

Student and institutional data is never used to train, fine tune, or otherwise improve any model, whether Scholera operated or provider operated. This is enforced contractually with providers and architecturally in our pipeline. Any code path that would send data to a provider endpoint without training opt out configured is a critical defect.

AI interactions are logged by encrypted user identifier with timestamp and action, per our audit commitments.
Logs capture what is required for institutional audit and oversight. They do not capture more than that.
Log retention follows the retention schedule in the Privacy Management Program.

Before adding a dependency, the engineer confirms:

The functionality cannot reasonably be implemented directly. A one function utility package is a supply chain liability with no offsetting benefit.
The package is actively maintained, with recent commits and responsive issue handling.
The package has no known unremediated critical vulnerabilities.
The license is compatible with Scholera's commercial use.
The transitive dependency tree is proportionate. A package that pulls in dozens of transitive dependencies for a small benefit is rejected.

New dependencies in a pull request are called out explicitly in the description with a one line justification.

Lockfiles are committed and are authoritative. Installs in CI and production use the lockfile exclusively.
Dependency versions are pinned. Floating major and minor ranges in production dependencies are prohibited.
Lockfile changes in a pull request receive specific reviewer attention. An unexplained lockfile diff is a review blocker.

Automated dependency vulnerability scanning runs against the repository, with findings triaged by severity per Section 12. A documented process for tracking third party and open source library currency, maintenance status, and long term availability is under development. See Section 20.

Severity	Definition	Target Remediation
Critical	Remote code execution, authentication bypass, unauthenticated access to Restricted data, active exploitation	24 hours
High	Privilege escalation, authenticated access to data outside role scope, significant data exposure	7 days
Medium	Vulnerability requiring specific conditions or limited impact	30 days
Low	Minimal impact, defense in depth improvement	90 days or next planned release

The clock starts at identification, not at triage.

Where a patch is not immediately available, mitigation is applied within the Critical or High remediation window even if full remediation is not yet possible. Acceptable interim measures include disabling the affected feature, restricting access to the affected path, applying a virtual patch or WAF rule, tightening rate limits, or increasing monitoring on the affected surface.

An unpatched Critical vulnerability with no mitigation applied is not an acceptable state. If neither patch nor mitigation is possible, the affected functionality is disabled.

A formal policy governing interim risk mitigation between vulnerability identification and patch application is under development. See Section 20.

Current and planned scanning coverage is stated in Section 20 rather than described here, so that this document does not represent a planned control as an operating one.

Every change to production follows this sequence without exception:

Step	Requirement
1. Branch	Work occurs on an isolated branch. Direct commits to the main branch are prohibited.
2. Authorization	Peer review by an engineer other than the author. Reviewer verifies Appendix A.
3. Impact analysis	Reviewer assesses scope and downstream effect on existing functionality, integrations, and data handling.
4. Testing	Validated in staging. Functional behavior, integration integrity, and regression against existing features.
5. Validation	Confirmed by the CTO before promotion.
6. Deployment	Promoted to production through the defined release process.
7. Rollback readiness	Rollback capability maintained for every deployment.

No change bypasses this sequence. Urgency is handled by Section 13.3, not by skipping steps.

The following receive heightened review and may not be approved by a reviewer who did not read the full diff:

Authentication or session handling
Authorization logic or role definitions
Prompt templates and retrieval scoping
Encryption, key handling, or identifier pseudonymization
Database schema affecting Restricted data
Third party integration configuration
Infrastructure, network, or CORS configuration
Dependency additions and lockfile changes
Logging configuration

Where a critical production issue requires unscheduled deployment:

The CTO authorizes the emergency deployment. Authorization may be verbal at the time and must be confirmed in writing within 24 hours.
The change is committed through version control, preserving the audit trail, even when the review step is compressed.
Post deployment review by a second engineer occurs within 48 hours.
The change is logged with the triggering issue, the authorizer, what was changed, and what review occurred after the fact.

A formal emergency change procedure covering authorization, documentation standards, and after the fact approval workflow is under development. See Section 20.

Scholera is a continuously delivered cloud platform serving all institutions from a single centrally managed instance. There are no parallel version branches, no installable client software, and no per institution deployments. Every user is on the current version at all times.

Security relevant events are logged with timestamp, actor as encrypted identifier, action, and outcome:

Authentication attempts and outcomes
Authorization failures
Administrative and configuration changes
Production data access by Scholera personnel
AI feature interactions per Section 10.7
Data export, deletion, and rights request execution
Deployment events

Secrets, session tokens, raw personal identifiers, full request bodies containing Restricted data, and AI prompt content beyond what audit commitments require.

Log statements are reviewed for this in every pull request. Logging is a common and quiet source of data exposure precisely because it feels harmless while writing it.

Logs are stored in a tamper resistant environment separate from the application. Retention follows the Privacy Management Program schedule. Institutional administrators may request audit log exports for their own deployment.

Alerting is configured for authentication anomalies, repeated authorization failures suggesting enumeration, anomalous AI token consumption, error rate spikes, and unexpected production access. Alerts route to the CTO.

Production, staging, and development are separated with no shared credentials and no shared data stores.
Production Restricted data is never copied into staging, development, or local environments. Non-production environments use synthetic or anonymized data.
Non-production environments are not publicly accessible without authentication.
A production credential is never present on an engineer's local machine except where explicitly provisioned for a documented purpose.

Per Section 10.3 of the Privacy Management Program:

Access follows least privilege and is scoped to role.
Administrative access to an institutional instance is not granted by default.
Access is provisioned only by the CTO. No engineer self provisions.
Access to production personal data requires documented work related justification specifying reason and scope.
Curiosity is not a justification. Accessing institutional or student data without a work related reason is a privacy non-compliance event subject to disciplinary action up to termination.

The CTO reviews all production access quarterly, confirms each grant remains appropriate, and revokes what is no longer necessary. Reviews are recorded in the Access Review Log.

On role change or departure, all access is revoked promptly and revocation is confirmed before offboarding is considered complete.

Any device used to access production systems or Restricted data must have full disk encryption enabled, an automatic screen lock, a current operating system with security updates applied, and no shared user account.

Infrastructure configuration is managed and version controlled by the CTO, providing a documented baseline and change history.
Default deny network posture. Services expose only the ports and endpoints they require.
CORS is configured with an explicit origin allowlist. Wildcard origins are prohibited in production.
Security headers are enforced at the edge: HSTS, Content Security Policy, X-Content-Type-Options, Referrer-Policy, and frame ancestor restrictions.
Administrative interfaces of infrastructure providers are protected by multifactor authentication. See Section 20 for enforcement status.
Backups are encrypted. Backup retention behavior is documented so that deletion commitments account for it. A deletion commitment that ignores backup retention is a commitment Scholera cannot honor.
Configuration changes follow Section 13.

Every engineer has an affirmative obligation to report a suspected security issue to the CTO immediately, and no later than 24 hours. This applies regardless of who caused it, including where the reporter caused it, and including where the reporter believes it may be minor or already resolved.

Scholera does not retaliate against good faith reporting. An engineer who reports their own mistake within an hour has protected the company. The same mistake concealed and discovered later has harmed it, and the disciplinary framework reflects that distinction explicitly.

Contain before investigating. Revoke the credential, disable the feature, restrict the path. Understanding can wait; exposure cannot.
Preserve evidence. Do not delete logs, force push over history, or destroy artifacts needed to establish scope.
Do not communicate externally. All institutional, regulatory, and public communication is handled by the Privacy Program Owner.
Document as you go. Time of detection, what was observed, what was changed, in real time rather than reconstructed later.

The CTO assesses scope and severity and engages the Privacy Program Owner where personal data may be affected. Institutional notification within 72 hours of discovery, regulatory notification, and remediation follow Section 13 of the Privacy Management Program.

Root cause analysis within 30 days of closure, focused on the control that should have prevented it rather than on the individual who encountered it. Resulting control changes are recorded and, where they alter engineering requirements, incorporated into this standard.

Any external party contributing code or receiving system access must, before access is granted:

Execute a written agreement including confidentiality, intellectual property assignment, and security obligations
Acknowledge this standard in writing
Receive access scoped to the narrowest set required, provisioned by the CTO
Use individual named accounts. Shared accounts are prohibited without exception.
Meet the endpoint requirements in Section 15.4
Agree that all work occurs in Scholera controlled repositories and environments
Agree that Restricted data is never copied, exported, or retained on external systems

Contractor code is subject to identical review requirements. There is no expedited path for external contributors, and in practice contractor changes warrant closer review because the contributor has less context on the system's invariants.

On engagement end: access revoked same day, credentials the contractor held rotated, repository access removed, and any Scholera data on contractor systems deleted with written confirmation.

Any service provider processing, storing, or transmitting Scholera data must meet the following before integration:

Requirement	Detail
Contractual instrument	Data Processing Agreement or equivalent, executed before any production data flows
Purpose limitation	Provider may use data only to deliver the contracted service
Training prohibition	Explicit contractual prohibition on using Scholera data for model training or product improvement requiring identification
Encryption	TLS in transit, encryption at rest
Breach notification	Defined notification obligation with a stated maximum timeline
Subprocessor disclosure	Provider discloses its own subprocessors and notifies of changes
Access controls	Provider supports role scoped access and MFA on administrative accounts
Deletion on termination	Data deleted on termination with written confirmation, and a stated backup expiry window
Assessment	Privacy and security assessment completed per Section 7.3 of the Privacy Management Program and recorded in the Vendor Register

Engineers may not integrate a new third party service that receives Scholera data without CTO approval and completion of the assessment. This includes analytics tools, error monitoring services, developer utilities, and anything else that receives request data. A tool added to solve a debugging problem is a subprocessor if it receives Restricted data, and it must be treated as one.

Provider	Function	Data Received
Supabase	Database, authentication, storage	Restricted, Internal
Google (Gemini)	LLM inference	Restricted (query and retrieval context)
Google (OAuth)	Identity provider	Restricted (identity assertions)
ElevenLabs	Voice synthesis	Content submitted for synthesis

DPA verification status for each provider is tracked in Section 20. A subprocessor operating under standard consumer or developer tier terms rather than an enterprise agreement is a material gap and a remediation priority.

Every engineer and contractor reads and acknowledges this standard before receiving repository or system access.
Onboarding covers this standard, the reporting duty in Section 17.1, data classification in Section 4, production access rules in Section 15, and the AI specific requirements in Section 10.
Refresher review occurs annually and upon material revision.
Acknowledgments are recorded and retained.

Scholera is an early stage company. This section states plainly what is implemented, what is not, and when the gaps close. It is the authoritative reference for any commitment made in an institutional security assessment. Where this section and any narrative elsewhere disagree, this section governs.

TLS in transit, AES 256 at rest
SSO through Google OAuth 2.0 with no end user passwords issued or stored
Role based access control with tenant scoping
Encrypted user identifiers in interaction logging
Peer review required on all changes, staging validation before production, rollback capability maintained
AI architectural controls: retrieval scoping, no open internet access, no model initiated state changes, no student data in training pipelines, per request token caps
Human oversight required for all grade, integrity, and record affecting decisions
Least privilege production access provisioned solely by the CTO with documented justification
Non-production environments use synthetic or anonymized data
Confidentiality and security policy acknowledgment at onboarding
Deliberately constrained subprocessor surface

#	Item	Commitment	Target	Owner
1	Enforce MFA on all administrative accounts across identity provider, cloud infrastructure, database, and internal tooling, applied at the provider level rather than per account	HECVAT: MFA for administrative accounts	Q4 2026	CTO
2	Verify or execute formal DPAs with Supabase, Google Gemini, Google OAuth, ElevenLabs, and hosting provider; confirm enterprise tier terms and contractual training prohibition	HECVAT: third party liability and contractual standards	Q4 2026	COO
3	Complete verification of all outstanding entries in the Data Inventory	Privacy Management Program Section 3	Q4 2026	CTO
4	Map existing controls to NIST AI RMF functions: Govern, Map, Measure, Manage	HECVAT: AI risk management processes	Q4 2026	COO
5	Stand up recurring external vulnerability scanning with defined cadence, severity triage, and documented remediation thresholds	HECVAT: external vulnerability scanning	Q1 2027	CTO
6	Implement authenticated vulnerability scanning gated in the pre release validation step	HECVAT: authenticated scanning prior to release	Q1 2027	CTO
7	Automated secret scanning across repository and commit history	Section 8	Q1 2027	CTO
8	Documented vulnerability and patch management policy including interim risk mitigation measures, classification criteria, and remediation timelines by severity	HECVAT: risk mitigation before patches applied	Q1 2027	CTO
9	Formal emergency change procedure covering authorization, documentation, and after the fact approval	HECVAT: emergency change documentation and authorization	Q1 2027	CTO
10	Documented process for third party and open source library currency, maintenance status, and long term availability validation	HECVAT: library validation and currency	Q1 2027	CTO
11	Documented onboarding and offboarding procedure with security training checkpoints, sign off, and access revocation checklist	HECVAT: onboarding and offboarding training	Q1 2027	COO
12	AI risk register and internal AI policy documentation	HECVAT: documented AI risk processes	Q1 2027	COO
13	System architecture diagram and full component data flow documentation	HECVAT: architecture and data flow diagrams	Q1 2027	CTO
14	Cookie consent interface and Privacy Center with structured request form	Privacy Policy commitments	Q1 2027	CEO
15	Formal stop processing and data subject rights request procedure	Privacy Management Program Section 5	Q1 2027	COO
16	Published FERPA data processing documentation on the Scholera website	HECVAT: FERPA data documentation	Q1 2027	COO
17	Third party security assessment of application and infrastructure	HECVAT: third party security assessment	Q2 2027	CTO
18	Formal third party risk management program with annual vendor review cycle and risk register	HECVAT: third party management strategy	Q2 2027	COO
19	Security and privacy review checkpoints formalized into sprint and release cycles	HECVAT: security in the product lifecycle	Q2 2027	CTO
20	Documented internal audit framework	HECVAT: internal audit processes	Q2 2027	COO
21	Publicly posted AI governance documentation	HECVAT: AI policies conspicuously posted	Q2 2027	COO
22	Documented technical and procedural process library mapped to NIST AI RMF	HECVAT: AI RMF documented processes	Q2 2027	COO
23	Formal configuration management policy with baseline configurations, drift detection, and review cadence	HECVAT: systems management and configuration	Q2 2027	CTO
24	Security controls inventory and gap assessment against NIST Cybersecurity Framework	HECVAT: industry standard security framework	Q1 2027	CTO
25	NIST CSF remediation roadmap and policy documentation	HECVAT: security framework conformance	Q2 2027	CTO
26	Formal NIST CSF alignment and internal ratification	HECVAT: security framework conformance	Q3 2027	CTO
27	SOC 2 Type I readiness assessment and controls documentation	HECVAT: SSAE 18 / SOC 2	Q1 2027	COO
28	SOC 2 Type I audit initiation	HECVAT: SSAE 18 / SOC 2	Q2 2027	COO
29	SOC 2 Type I audit completion	HECVAT: SSAE 18 / SOC 2	Q3 2027	COO
30	SOC 2 Type II audit initiation	HECVAT: SSAE 18 / SOC 2	Q4 2027	COO
31	Third party gap assessment against NIST AI RMF	HECVAT: AI risk framework validation	Q2 2027	COO
32	First transparency report on legal process requests	Privacy Management Program Section 6.7	Q4 2027	COO
33	SAML federated identity support and evaluation of Okta integration	HECVAT: SSO protocol support	Under evaluation	CTO
34	InCommon or eduGAIN trust federation participation	HECVAT: federation participation	Under evaluation	CTO

The roadmap is ordered so that cheap high impact controls land first and audit dependent work lands last.

Q4 2026 items are inexpensive, fast, and disproportionately visible to institutional reviewers. MFA enforcement in particular is the single highest value item on this list: it is hours of work, it closes the gap most likely to draw scrutiny in a security assessment, and it converts a No to a Yes on a question every institution asks.

Q1 2027 establishes the documentation and scanning layer. Most of these items formalize practices that already exist informally, which is faster than building new capability.

Q2 2027 brings in external validation and framework alignment, which depends on the documentation from Q1 existing first.

Q3 and Q4 2027 complete formal audit and certification, which cannot meaningfully begin until the preceding layers are in place. Attempting SOC 2 before the controls documentation exists produces an expensive finding list rather than a certification.

The CTO and COO review this roadmap quarterly. A missed target is recorded with a revised date and a reason. Targets are not silently moved. Where a commitment has been made to an institution in a security assessment response, that institution is notified if the date changes materially.

All Appendix A items satisfied for every change in the release
Staging validation complete: functional, integration, and regression
Dependency vulnerability scan reviewed; no unremediated Critical or High findings
No debug endpoints, verbose error modes, or diagnostic routes reachable in production
Security headers and CORS configuration verified unchanged or intentionally updated
Rollback path confirmed
CTO validation and deployment authorization recorded
Institutional administrators notified where the change materially affects platform behavior

Employment or contractor agreement executed, including confidentiality and IP assignment
This standard read and acknowledged in writing
Privacy Management Program obligations reviewed, including the 24 hour reporting duty
Data classification model in Section 4 reviewed
Endpoint requirements verified: full disk encryption, screen lock, current OS, no shared account
MFA enabled on all provisioned accounts
Access provisioned by the CTO, scoped to role, recorded in the Access Review Log
Individual named accounts only; no shared credentials issued

All system, repository, and infrastructure access revoked
Any secrets or credentials the individual could access rotated
Production access grant removed and recorded in the Access Review Log
Scholera data removed from any personal or contractor controlled device, with written confirmation
Continuing confidentiality obligations acknowledged
Revocation confirmed by the CTO before offboarding is closed

Scholera Inc.

Standard Owner: Harshil Patel, Chief Technology Officer
Security and Privacy Contact: Pat Roscio, Chief Operating Officer
Email: proscio@scholera-inc.com
Location: New Jersey, United States

Institutional partners may request this standard, the Privacy Management Program, or supporting documentation at any time. Questions from institutional security reviewers have materially improved this document and are welcome.

Document Control

1. Purpose, Scope, and Authority

1.1 Purpose

1.2 Scope

1.3 Relationship to Other Documents

1.4 Authority and Exceptions

1.5 Non-Compliance

2. Security Principles

3. Roles and Responsibilities

4. Data Classification

5. Secure Development Lifecycle

5.1 Design Phase

5.2 Threat Modeling

5.3 Implementation

5.4 Review

5.5 Pre Release Validation

5.6 Deployment

5.7 Post Deployment

6. Secure Coding Requirements

6.1 Input Handling

6.2 Output Encoding and Injection Prevention

6.3 Error Handling

6.4 General Prohibitions

6.5 AI Coding Assistants

7. Authentication and Authorization

7.1 Authentication

7.2 Authorization

7.3 Role Model

8. Secrets Management

9. Cryptography and Data Protection

9.1 Standards

9.2 User Identifier Encryption

9.3 Transport

10. AI and LLM Security Requirements

10.1 Architectural Boundaries

10.2 Prompt Construction

10.3 Prompt Injection

10.4 Resource Controls

10.5 Human Oversight

10.6 Training Data Prohibition

10.7 Logging of AI Interactions

11. Dependency and Supply Chain Management

11.1 Selection

11.2 Integrity

11.3 Monitoring and Currency

12. Vulnerability and Patch Management

12.1 Severity and Remediation Targets

12.2 Interim Mitigation

12.3 Scanning

13. Change Management and Release

13.1 Standard Process

13.2 Security Relevant Changes

13.3 Emergency Changes

13.4 Version Currency

14. Logging, Monitoring, and Alerting

14.1 What Is Logged

14.2 What Is Never Logged

14.3 Log Integrity and Retention

14.4 Alerting

15. Environment Separation and Production Access

15.1 Environment Rules

15.2 Production Access

15.3 Access Review and Revocation

15.4 Endpoint Requirements

16. Infrastructure and Configuration

17. Incident Response for Engineers

17.1 Reporting Duty

17.2 Non-Retaliation

17.3 Immediate Actions

17.4 Escalation

17.5 Post Incident

18. Third Party and Contractor Requirements

18.1 Contract Engineers and Agencies

18.2 Third Party Service Providers

18.3 Current Subprocessors

19. Training and Acknowledgment

20. Security Roadmap and Current Posture

20.1 Implemented

20.2 Roadmap

20.3 Sequencing Rationale