Information Security Policy

1. Purpose & Scope

This Information Security Policy establishes the principles, requirements, and responsibilities for protecting EduCreds Labs' information assets, systems, and infrastructure. It applies to all founders, employees, contractors, advisors, and third parties who access EduCreds systems or handle EduCreds data.

EduCreds processes sensitive academic data on behalf of educational institutions. Maintaining the security, integrity, and availability of this data is a core obligation to our institutional clients, their students, and to the trust framework the platform is built upon.

2. Information Classification

Classification	Description	Examples	Handling
Public	Information approved for public release	Marketing content, public docs, open API specs	No restrictions
Internal	Internal use only, not for external distribution	Internal processes, meeting notes, roadmaps	Not shared externally without approval
Confidential	Sensitive business or technical information	Source code, architecture docs, investor materials, contracts	Shared only on need-to-know basis; NDA required for third parties
Highly Confidential	Highest sensitivity — breach could cause severe harm	Private keys, credentials, student PII, investor cap table, legal agreements	Strict access controls, encrypted at rest, audit logged

3. Access Control

3.1 Principle of Least Privilege

All system access is granted on a need-to-know, least-privilege basis. Users receive only the minimum access required to perform their role. Access rights are reviewed when roles change and revoked immediately upon departure.

3.2 Authentication Requirements

Multi-factor authentication (MFA) is mandatory for all production system access, cloud console access, and administrative accounts
Passwords must be at least 16 characters and managed via a password manager
Service accounts use API keys or managed identities — never shared passwords
SSH access to production infrastructure requires key-based authentication; password-based SSH is disabled

3.3 Role-Based Access Control (RBAC)

Platform roles: Admin, Institution Staff, Verifier, Developer — each with defined permission sets
Azure resources: scoped IAM roles per service, no wildcard permissions
Database access: application-level only; no direct production database access except for COO and authorised debugging sessions (logged)

4. Credential & Key Management

4.1 Azure Key Vault

All secrets, API keys, database credentials, and cryptographic keys are stored in Azure Key Vault. No secrets are stored in source code, environment variable files committed to version control, or configuration files in repositories.

4.2 Credential Signing Keys

W3C Verifiable Credential signing uses ES256 (ECDSA P-256)
Institution signing keys are generated per institution and stored in Key Vault
Key rotation policy: annual or immediately upon suspected compromise
Key ceremony documented and witnessed for root keys

4.3 Blockchain Wallet Keys

Platform operational wallets use hardware security module (HSM) where available
Private keys never transmitted in clear text or logged
Multi-signature governance wallet for protocol-level operations

5. Encryption

Context	Standard	Implementation
Data in transit	TLS 1.2 minimum (TLS 1.3 preferred)	Azure Container Apps enforced HTTPS; HSTS enabled
Data at rest	AES-256	Azure managed disk encryption; IPFS content encrypted before upload
Credential signing	ES256 (ECDSA P-256)	Per-institution signing key via Key Vault
Database	TDE (Transparent Data Encryption)	Azure PostgreSQL encryption at rest
Connector Agent communications	HMAC-SHA256 + TLS	mTLS optional for Tier 1 enterprise deployments

6. Audit Logging

All API requests, authentication events, and administrative actions are logged to Azure Application Insights
Logs are append-only and tamper-evident — no deletion or modification by application-level roles
Connector Agent maintains an append-only local JSONL audit log of all SIS data requests
Log retention: 90 days in Application Insights; archival to cold storage for 2 years
Privileged access events (key vault access, production deployments) generate alerts
Student PII is never included in application logs

7. Incident Classification & Response

Severity	Definition	Response Time	Notification
P1 — Critical	Data breach, complete service outage, credential forgery detected	Immediate (within 1 hour)	Affected institutions within 72 hours; legal counsel engaged
P2 — High	Partial service degradation, suspected unauthorised access, key exposure	Within 4 hours	Internal escalation; institutions notified if data affected
P3 — Medium	Single service failure, performance degradation, failed login anomaly	Within 24 hours	Internal tracking; post-incident report
P4 — Low	Non-critical bugs, minor anomalies, informational alerts	Next business day	Tracked in issue queue

All P1 and P2 incidents require a written post-incident report within 5 business days including root cause, impact, containment, and remediation steps.

8. Development Security

All code changes require peer review via pull request — no direct commits to main branches
Dependency scanning runs on every pull request (automated)
No personal data (student PII) included in test datasets; synthetic data only
Secrets scanning on all commits (pre-commit hooks + CI pipeline checks)
Third-party dependencies reviewed for known vulnerabilities before adoption
Smart contracts reviewed for common vulnerability patterns (reentrancy, integer overflow, access control) before deployment

9. Third-Party & Cloud Security

Microsoft Azure: ISO 27001, SOC 2, GDPR compliant — EduCreds inherits baseline cloud security controls
IPFS/Pinata: All content encrypted before upload; EduCreds retains encryption keys
Third-party integrations: Security review required before integration; minimum required permissions only
Vendor access to EduCreds systems requires signed NDA and limited-scope credentials

10. On-Chain Privacy Principle

Student PII is never written to any public blockchain. Only cryptographic hashes, credential IDs, institution identifiers, IPFS URIs, and revocation status are anchored on-chain. Names, email addresses, grades, biometric data, and academic records are stored off-chain and encrypted. This is a hard architectural constraint, not a configuration option.

11. Policy Review

This policy is reviewed annually by the COO and CEO, or immediately following a P1/P2 security incident. All founders and team members must acknowledge this policy upon joining and following any material update.

Next review date: August 2027

Policy owner: Sekiziyivu Paul, COO

Approved by: Kyotoyinze Abdulmajid, CEO