SECURITY & PRIVACY
Your Human Capital Data Deserves More Than a Password.
DISHA 4.0 HCOS is designed to protect human-capital information through layered security, privacy engineering, controlled access, data governance and continuous assurance. We aim to make protection understandable — not merely invisible.
A layered shield built around a human-capital data object: Identity → Consent → Access → Encryption → Processing → Audit → Retention → Deletion.
Security protects systems and information. Privacy governs the legitimate and respectful use of information about people. Both are designed into DISHA from the architecture outward.
[PLACEHOLDER — SECURITY & PRIVACY POLICY OWNER] · [PLACEHOLDER — DPO / PRIVACY CONTACT] · [PLACEHOLDER — CISO / SECURITY OWNER] · Page spec v1.0 · [PLACEHOLDER — EFFECTIVE DATE]
What we can say today — and what we won't claim yet
Assurance is evidence, not badges. Each area below states its current honest status; nothing is shown as certified or compliant without an authoritative, in-date evidence record.
Encryption
[PLACEHOLDER — VERIFIED ALGORITHMS/PROTOCOLS: shown only after engineering validation]
Identity & access
Authentication, authorization and least privilege are enforced in the current platform; public detail is at approved-disclosure level only.
Privacy
Purpose limitation, minimization and rights routes are designed in; consent/permissions centre detail pending.
Auditability
Governed evidence records exist in the Data Fabric (append-oriented ledgers); public audit detail pending.
Availability
[PLACEHOLDER — SLA published only if contractually and operationally substantiated]
Independent assurance
[PLACEHOLDER — no certification badge is displayed without certificate, scope and validity metadata]
Data residency
[PLACEHOLDER — actual supported regions and configuration options]
Claims from earlier site versions (AES-256, TLS 1.3, zero-trust architecture, field-level security, SOC 2 Type II, ISO 27001, GDPR/DPDP/CCPA, uptime figures) are treated as claims requiring source-of-truth validation — they are NOT republished here as verified facts.
One architecture, two domains
Security domain — protects systems and information
Human Capital Data
Privacy domain — governs how information about people is used
Data protection
DISHA protects data throughout its lifecycle — from collection and ingestion to processing, storage, transmission, backup, sharing, archival and deletion. Controls are layered so a single failed control does not expose an entire environment.
Encryption at rest
[PLACEHOLDER — verified mechanism and scope]
Encryption in transit
[PLACEHOLDER — verified transport protocols and scope]
Application/data-layer protection
Database, object-store and sensitive-field protections explained at a safe level; field-level controls are customer-configurable areas.
Key management
Separation of duties, rotation, storage and access — high level; details pending verification.
Secrets management
No credentials or secrets in application code or public repositories.
Backup protection
Encrypted, access-controlled, monitored backups with defined recovery objectives (objectives pending publication).
Deletion
Secure deletion/expiry processes according to retention requirements.
Environment separation
Development, test, staging and production data are separated.
Identity & access management
Access to human-capital data is granted according to identity, role, purpose, tenant, context and least privilege — not simply because a user can reach the application.
| Control | Page content |
|---|---|
| Authentication | Supported methods described; SSO/federation only where actually available. |
| Authorization | Role- and attribute-based access controls govern the current platform. |
| Least privilege | Users/services receive only required permissions. |
| Privileged access | Separate privileged accounts, approval, monitoring and review. |
| Session security | Timeout, token lifecycle, revocation and device/session controls. |
| MFA | [PLACEHOLDER — supported enforcement options; no universal-enforcement claim] |
| Service identity | Machine-to-machine credentials, rotation and scoped permissions. |
| Access reviews | Periodic review of privileged and sensitive access. |
| Tenant isolation | Logical/technical controls preventing cross-tenant access. |
Zero-trust security model
- Verify identity before access.
- Authenticate every service-to-service request according to the actual architecture.
- Authorize each requested action, not merely the user session.
- Limit network and application trust boundaries.
- Continuously monitor high-risk activity.
- Segment workloads and sensitive environments where appropriate.
- Record security-relevant events.
- Assume controls can fail and design layered containment.
Application & API security
Secure development lifecycle covering design, code review, dependency management, testing and release.
API authentication and authorization with scoped permissions.
Input validation and output encoding.
Rate limiting and abuse protection.
Protection against common web/API threats.
Secure file upload and malware scanning where files are accepted.
Secrets and configuration management.
Dependency and container/image scanning.
Security testing before material releases.
Vulnerability disclosure and remediation process.
Infrastructure & cloud security
| Cloud accounts | Strong identity controls, separation of duties, logging and environment segregation. |
| Network | Segmentation, private connectivity where appropriate, controlled ingress/egress. |
| Compute | Hardened images, patching, workload isolation and endpoint/runtime monitoring. |
| Containers | Signed/trusted images, scanning, least privilege and runtime controls. |
| Storage | Encryption, access policies, lifecycle management and backup. |
| Databases | Encryption, least privilege, auditing, backup and recovery testing. |
| Secrets | Centralised secret management; no secrets in source code. |
| Monitoring | Security telemetry, alerting and incident response integration. |
| Resilience | Defined RTO/RPO, backups, disaster recovery and recovery testing. |
[PLACEHOLDER — CLOUD PROVIDER(S), REGIONS, ARCHITECTURE DIAGRAM AND VERIFIED SECURITY CONTROL REGISTER]
Privacy by design
Privacy is designed into product architecture before a feature is released. A privacy review asks not only “Is this data allowed?” but also “Do we need this data at all?”
- Define purpose before collection.
- Minimise data fields.
- Prefer aggregated or de-identified information where individual-level data is unnecessary.
- Separate identity data from analytical data where practical.
- Use privacy-preserving defaults.
- Restrict secondary use.
- Provide meaningful transparency.
- Build correction/deletion pathways into data models.
- Design retention at the beginning rather than after storage accumulates.
- Evaluate privacy risk when a feature, dataset, vendor or model materially changes.
Data classification
| Class | Examples | Expected controls |
|---|---|---|
| Public | Public website content, approved publications | Integrity, availability and standard web security. |
| Internal | Internal operational information | Authenticated access and controlled sharing. |
| Confidential | Contracts, non-public business information | Least privilege, encryption, controlled disclosure. |
| Personal | Identity/contact/profile information | Purpose limitation, access control, retention and rights handling. |
| Sensitive / High impact | Health, financial, credentials or other specially protected information where processed | Enhanced access, encryption, minimisation, monitoring and purpose-specific governance. |
| Restricted | Secrets, security keys, incident investigations, privileged security data | Strong isolation, privileged access and strict audit controls. |
[PLACEHOLDER — DISHA DATA CLASSIFICATION POLICY AND EXACT SENSITIVE-DATA CATEGORIES]
Trace my data
A fictional person moves through the DISHA data lifecycle, step by step — making privacy and security tangible without exposing production telemetry.
ILLUSTRATIVE — SYNTHETIC DATA — NOT A REAL PERSON
Asha R. (synthetic) · Learner
Step 1 of 10
1 · Profile created
Asha creates a DISHA account: name, email, organization, stated interest. Nothing else is asked.
ILLUSTRATIVE — SYNTHETIC DATA — NOT A REAL PERSON
Consent, permissions & user control
Consent is one privacy mechanism — not a substitute for a complete privacy governance framework. DISHA distinguishes consent from contractual necessity, legal obligation, legitimate interests or other applicable bases, depending on jurisdiction.
- Show users what data is being requested.
- Explain why it is needed.
- Explain who will receive or access it where applicable.
- Explain duration/retention where appropriate.
- Provide granular choices where technically and legally required.
- Record consent evidence where consent is the lawful basis.
- Make withdrawal as understandable as grant, where withdrawal is applicable.
- Do not bundle unrelated purposes into one vague consent.
- Do not treat continued use of a service as automatic proof of consent where explicit consent is required.
[PLACEHOLDER — CURRENT CONSENT / PERMISSION CENTRE DETAILS AND POLICY RULES]
The data lifecycle
01 · COLLECT
Why do we need this data? What is the source?
02 · CLASSIFY
What sensitivity/category applies?
03 · STORE
Where is it stored? Who can access it?
04 · USE
What purpose and processing are permitted?
05 · SHARE
Who receives it and under what authority/contract?
06 · RETAIN
How long is it needed and why?
07 · DELETE
How is it securely deleted or de-identified?
Data residency & sovereignty
Where data is stored and processed can matter for legal, contractual, operational and institutional requirements. Residency options are disclosed only where they are genuinely available.
- Country/region/availability-zone information where publishable.
- Customer-configurable residency options where actually supported.
- Cross-border transfer mechanisms where relevant.
- Backup and disaster-recovery geography.
- Subprocessor processing locations.
- Lawful access and government-request handling policy at an appropriate level.
- Data movement restrictions for regulated deployments.
[PLACEHOLDER — VERIFIED DATA RESIDENCY MAP AND CROSS-BORDER TRANSFER MECHANISM REGISTER]
Multi-tenancy & tenant isolation
DISHA is a multi-tenant, cloud-native platform. Tenant isolation is explained without exposing implementation secrets.
[PLACEHOLDER — APPROVED TENANT ISOLATION ARCHITECTURE DIAGRAM]
Audit logging & evidence
Security and privacy controls are more credible when material events can be evidenced. DISHA maintains audit records appropriate to the risk of the activity; the Data Fabric already carries append-oriented evidence ledgers, and public detail expands as verification completes.
Identity
Login, MFA, authentication failure, session events.
Authorization
Permission changes, privileged access, access denials.
Data access
Sensitive-record access where logging is appropriate and lawful.
Data change
Material changes to records, configurations or policies.
Consent
Grant, withdrawal or change where consent is recorded.
Administrative actions
Role, policy, integration and configuration changes.
Security events
Alerts, detections, incident actions.
AI/system events
Material model/configuration changes where relevant to security/privacy.
Monitoring & detection
- Continuous monitoring of security-relevant events.
- Anomaly detection where appropriate.
- Alert severity and triage.
- Privileged-access monitoring.
- Abuse/rate-limit monitoring.
- Data-exfiltration indicators where supported.
- Configuration drift monitoring.
- Vulnerability monitoring.
- Security incident escalation.
- Privacy incident detection and assessment.
Vulnerability management
A high-level statement — no exploitable details are published.
- Asset inventory.
- Continuous or scheduled vulnerability scanning as appropriate.
- Dependency scanning.
- Penetration testing.
- Severity classification.
- Remediation targets.
- Exception/risk acceptance process.
- Verification after remediation.
- Disclosure process for material vulnerabilities.
[PLACEHOLDER — PENETRATION TEST / VULNERABILITY MANAGEMENT DISCLOSURE POLICY, MOST RECENT TEST DATE AND PUBLIC REPORT AVAILABILITY]
Security incident response
Detect
Identify suspicious or confirmed events.
Triage
Determine severity, scope and affected systems/data.
Contain
Limit damage and preserve evidence.
Eradicate
Remove root cause or malicious access.
Recover
Restore services and validate controls.
Notify
Notify affected parties/regulators where required.
Learn
Post-incident review and corrective actions.
[PLACEHOLDER — SECURITY INCIDENT REPORTING EMAIL/FORM, ESCALATION TARGETS AND NOTIFICATION POLICY]
Privacy incident / personal data breach response
A security event may not always be a personal-data breach, and a privacy issue may occur without a classic cyberattack. Privacy incidents are handled on their own path.
- Identify whether personal data is involved.
- Determine categories and approximate scope.
- Assess affected jurisdictions and contractual obligations.
- Assess risk to individuals.
- Contain and remediate.
- Document decisions and evidence.
- Notify regulators/customers/individuals where required.
- Provide correction, support or mitigation where appropriate.
- Perform post-incident improvement.
Your privacy rights
Jurisdiction-aware rights and mechanisms — connected to real operational routes as they come online.
[PLACEHOLDER — ACTUAL DATA SUBJECT REQUEST PORTAL / EMAIL / FORM / IDENTITY-VERIFICATION PROCESS / RESPONSE TARGETS]
Children, students & vulnerable users
DISHA serves education, students and families. Age-appropriate protections apply where those populations are actually supported.
- Age/eligibility rules for products that serve minors.
- Parental/guardian controls where legally required.
- Minimisation of student data.
- Restricted visibility of sensitive student information.
- Clear family/guardian permissions.
- Retention and deletion controls.
- Special handling of educational records.
- Safeguards against profiling or inappropriate inference.
- Child-friendly privacy explanations where required.
[PLACEHOLDER — DISHA AGE-GATING / CHILD PRIVACY / STUDENT DATA POLICY, SUBJECT TO LEGAL REVIEW]
Third-party vendors & subprocessors
A register is maintained where policy permits; subprocessor changes follow a controlled notification process where contract/law requires it.
Vendor
Legal entity name
Service
What service is provided
Purpose
Why DISHA uses it
Data category
High-level categories processed
Location
Processing geography where appropriate
Role
Processor/subprocessor/service provider/etc.
Security assurance
Relevant independently verified assurance where available
Contract status
Current/approved status
Last reviewed
Date
[PLACEHOLDER — CURRENT SUBPROCESSOR REGISTER AND CHANGE-NOTIFICATION MECHANISM]
Enterprise Trust Centre
A structured route for CISOs, CTOs, DPOs, procurement teams and security reviewers — a workflow, not a generic contact link.
Request a security review
Submissions route to the accountable team; approved material is provided through controlled channels. Restricted security documents are never exposed through public URLs.
Workflow: SUBMIT → VALIDATE → ROUTE → VERIFY REQUESTER → NDA/ACCESS CHECK → PROVIDE APPROVED MATERIAL → TRACK → CLOSE
Compliance & assurance centre
Assurance is presented as evidence, not badges.
| Assurance type | Required public evidence |
|---|---|
| Certification | Certificate, scope, issuer, issue/expiry date and status. |
| Independent audit | Audit type, period, scope and report availability. |
| Penetration test | Test date, scope and controlled report availability. |
| Legal assessment | Jurisdiction, subject, date and counsel status where publishable. |
| Privacy assessment | DPIA/PIA availability and scope where appropriate. |
| Customer assurance | Approved questionnaire or trust package. |
[PLACEHOLDER — CURRENT CERTIFICATE/AUDIT REGISTER]
Compliance claims guardrail
- No certification badge without a valid certificate.
- No “compliant” statement without defined scope, jurisdiction and current assessment.
- Prefer “supports”, “designed to align with”, or “controls include” when certification/compliance is not formally established.
- Every claim has owner, evidence document, issue date, expiry/review date and approved wording.
- Expired certificates automatically disappear from the public page.
- Customer-specific compliance is never implied to be universal.
- Compliance with one framework does not imply compliance with another.
Business continuity & disaster recovery
- Availability architecture.
- Backup strategy.
- Recovery objectives.
- Disaster recovery testing.
- Regional failure handling.
- Critical dependency inventory.
- Communication during major outages.
- Recovery validation before returning to normal operations.
[PLACEHOLDER — VERIFIED RTO/RPO, BACKUP FREQUENCY, DR TEST CADENCE AND PUBLIC SLA LANGUAGE]
Security advisories & release transparency
Security advisories and versioned releases live in the platform's release-notes system; this page summarises their governance meaning rather than duplicating the changelog.
Privacy & security transparency dashboard
A public dashboard populated only from authoritative sources — assurance status, certificates in force, security tests, incidents with disclosure policy, subprocessor changes. Metrics that could expose exploitable information or mislead through an undefined denominator are never displayed; each live card states its source.
Certification claims displayed
0
Evidence-first rule: nothing shows as certified without a valid certificate, scope and dates
Legacy claims republished as verified
0
Old-site claims (encryption specifics, SOC 2, ISO 27001, GDPR…) stay under evidence review
Subprocessors publicly registered
0
The register is a governance placeholder — it appears when approved
Governed organizations under registry controls
4
Source: Registry, aggregate count only
Governed person records
8
Source: Registry, aggregate count only — never record content
Material security advisories published
0
None to date; the advisories system lives in release notes
“Who can see my data?”
Select a role to see the categories of information that role may access under an example policy. This is an illustrative model, not a disclosure of real permissions.
ILLUSTRATIVE — APPROVED SYNTHETIC POLICY MODEL — NOT REAL PERMISSIONS
Access under an example policy — Learner
Own profile and evidence; own Genome™ views; own learning and career outputs.
Security & privacy — questions, answered plainly
[PLACEHOLDER — CURRENT RESIDENCY OPTIONS AND DEPLOYMENT-SPECIFIC RULES].
Your data should be protected. Your privacy should be respected. Your trust should be verifiable.
The Security & Privacy page should make trust inspectable. Every important claim connects to a defined control, an owner, a scope, a date and — where possible — an evidence artifact.
Security & Privacy · Responsible AI · Privacy Policy · Data Protection · Compliance · Terms · Accessibility · Report an Issue · System Status · Security Advisories · Contact Us