Data Privacy & Security Policy, GitHub Usage, Code Security, and Learner Data Protection

  1. Overview
  2. Policies
  3. Data Privacy & Security Policy, GitHub Usage, Code Security, and Learner Data Protection

Applies To: All WyzLab employees, contractors, interns, and collaborators with access to company repositories, systems, and learner data

1. PURPOSE

This policy establishes WyzLab Solutions' standards for:

  1. Protecting learner privacy in compliance with the Philippine Data Privacy Act (RA 10173)

  2. Securing proprietary code and intellectual property in GitHub and related development tools

  3. Preventing data breaches, leaks, and unauthorized access to sensitive information

  4. Ensuring safe coding practices that protect both company assets and user data

  5. Defining clear responsibilities for all team members handling data and code

Why This Matters:

  • WyzLab processes personal data of thousands of learners (names, emails, progress, assessments).

  • Our code contains proprietary algorithms, business logic, and API keys.

  • A single breach could compromise learner trust, violate legal obligations, and damage our reputation.

  • Developers must understand what data is sensitive, how to protect it, and what to do if something goes wrong.

2. SCOPE

2.1 Who This Policy Covers

  • All developers (employees, interns, contractors) with access to:

    • GitHub repositories (wyzlab/wyzquests, wyzlab/wyzcore, etc.)

    • Production and staging environments

    • Learner data via Supabase, APIs, admin dashboards

    • Internal documentation, Figma, Google Drive

2.2 What This Policy Covers

  • Personal Data: Any information that identifies or can identify a learner, creator, or user

    • Names, email addresses, phone numbers

    • Quiz scores, progress data, certificates

    • IP addresses, session data, activity logs

    • Payment information (if applicable)

  • Proprietary Information: Company assets not meant for public disclosure

    • Source code (private repositories)

    • API keys, database credentials, environment variables

    • Business strategies, pricing, roadmaps

    • Client lists, partner agreements

  • Security Practices: How we write, review, store, and deploy code

    • GitHub workflows (branching, commits, pull requests)

    • Secret management (.env files, password storage)

    • Access control (who can merge, deploy, access production data)

    • Incident reporting (what to do when something goes wrong)

2.3 What This Policy Does NOT Cover (See Related Policies)

  • General employee conduct → See Employee Handbook

  • Intellectual property ownership → See Employment Contract

  • Non-GitHub tools (Slack, Agiled) → See Communication Policy

3. LEGAL AND REGULATORY FRAMEWORK

3.1 Philippine Data Privacy Act (RA 10173)

Key Principles We Must Follow:

  1. Transparency – Learners know what data we collect and why

  2. Legitimate Purpose – We only collect data necessary for training, certification, or support

  3. Proportionality – We don't over-collect (no home addresses for an online course)

  4. Data Security – Encryption, access control, regular audits

  5. Data Subject Rights – Learners can access, correct, or delete their data

  6. Accountability – If we breach, we report to NPC and affected users

Penalties for Non-Compliance:

  • Administrative fines (₱500K – ₱5M)

  • Criminal liability (imprisonment for serious breaches)

  • Civil damages (compensation to affected individuals)

  • Reputational harm (loss of trust, client contracts)

3.2 GitHub Terms of Service & Best Practices

  • Public repositories = public forever (even if deleted later)

  • Private repositories require proper access control

  • Leaked secrets (API keys) can be harvested by bots within minutes

  • GitHub Advanced Security features (secret scanning) help but aren't foolproof

4. DATA CLASSIFICATION

4.1 Public Data (Can Be Shared Freely)

  • Product marketing materials (WyzQuests landing pages)

  • Open-source libraries we publish

  • Public documentation (help articles, FAQs)

  • Job postings, company blog posts

4.2 Internal Data (For Team Use Only)

  • Design mockups (Figma files)

  • Internal wikis, onboarding docs

  • Meeting notes (non-confidential)

  • General project timelines

4.3 Confidential Data (Restricted Access)

  • Source code (private GitHub repos)

  • Database schemas, API documentation

  • Client agreements, pricing models

  • Product roadmaps, competitive analysis

4.4 Highly Sensitive Data (Extreme Protection Required)

  • Personal Identifiable Information (PII):

    • Learner names, emails, phone numbers

    • Quiz scores, assessment results

    • Certification records, payment details

  • Security Credentials:

    • API keys (Supabase, Gemini, Clerk, payment gateways)

    • Database passwords

    • OAuth tokens, session secrets

    • SSL certificates, private keys

Rule: Highly Sensitive Data must NEVER appear in:

  • Git commits

  • Slack messages (even DMs)

  • Screenshots shared externally

  • Console logs in production

  • Public error messages

5. GITHUB SECURITY POLICIES

5.1 Repository Access Control

Private Repositories Only (Until Further Notice):

  • All WyzLab code is in private repos (wyzlab/*).

  • Invite-only access via GitHub organizations.

Access Levels:

  • Read: Can view code, clone repos (QA, designers, non-dev stakeholders).

  • Write: Can push branches, open PRs (all developers).

  • Admin: Can merge to main/develop, manage settings (tech leads, Yza).

Onboarding Process:

  1. Intern/employee provides GitHub username.

  2. Wana or tech lead sends org invite.

  3. Intern accepts invite and gains access.

  4. If intern leaves: access revoked within 24 hours.

5.2 Branch Protection Rules

main branch:

  • Direct pushes: ❌ Blocked

  • Requires: 2 approving reviews before merge

  • Status checks must pass (linting, TypeScript, tests)

  • Only admins can override

develop branch:

  • Direct pushes: ❌ Blocked

  • Requires: 1 approving review

  • Automatic deployment to Dev Site after merge

Feature branches (feature/*, fix/*):

  • Anyone can push to their own branches

  • Deleted after merge (keep history clean)

5.3 Secret Management (CRITICAL)

Golden Rules:

  1. Never commit secrets to Git (even private repos)

    • ❌ API keys in code: const API_KEY = "sk_live_12345"

    • ❌ .env files committed to repo

    • ❌ Passwords in comments

    • ✅ Use environment variables: process.env.API_KEY

    • ✅ .env.local in .gitignore

  2. Use GitHub Secrets for CI/CD

    • Store production keys in GitHub Actions Secrets

    • Never echo secrets in workflow logs

  3. Rotate Compromised Secrets Immediately

    • If a key leaks (even in a private repo commit), assume it's compromised

    • Generate new key, update environment, revoke old key

    • Report to tech lead and Yza

Environment Variable Structure:

bash

# .env.local (NEVER COMMITTED)
NEXT_PUBLIC_SUPABASE_URL=https://xyz.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhb...public_safe_key
SUPABASE_SERVICE_ROLE_KEY=eyJhb...SENSITIVE_SECRET
GEMINI_API_KEY=AIza...SENSITIVE_SECRET
CLERK_SECRET_KEY=sk_live_...SENSITIVE_SECRET

.gitignore Must Include:

text

.env
.env.local
.env.production
*.pem
*.key
secrets/

5.4 Commit Hygiene

Good Commit Messages:

text

✅ feat: add QuestionCardLayout wrapper component
✅ fix: prevent SQL injection in user query endpoint
✅ chore: update dependencies for security patches

Bad Commit Messages:

text

❌ "fixed stuff"
❌ "asdfasdf"
❌ "Final final FINAL version"

What NOT to Commit:

  • Database dumps with real user data

  • Screenshots with learner names/emails

  • Postman collections with live API keys

  • node_modules (use .gitignore)

  • Personal notes with internal discussions

5.5 Code Review for Security

Reviewers Must Check:

  • No hardcoded secrets (search for api_key, password, secret)

  • No PII logged to console (search for console.log(user))

  • SQL queries use parameterized queries (not string concatenation)

  • User inputs are validated (Zod schemas, not raw req.body)

  • Error messages don't expose internal paths or stack traces to users

  • File uploads check file type and size (no arbitrary code execution)

If You Find a Security Issue:

  1. Don't approve the PR.

  2. Comment privately (don't expose vulnerability publicly).

  3. Suggest fix with example.

  4. If critical, escalate to tech lead immediately.

6. LEARNER DATA PROTECTION

6.1 Principles of Data Handling

Minimize Collection:

  • Only ask for data we need (name, email for account; progress for analytics).

  • Don't require home address, ID number, or sensitive personal info unless legally required (e.g., TESDA certification).

Encrypt at Rest and in Transit:

  • Supabase: data encrypted at rest by default.

  • All API calls: HTTPS only (no HTTP).

  • Passwords: hashed with bcrypt (never plain text).

Access Control:

  • Role-based: Learners see only their own data; Admins see aggregate; Instructors see cohort data.

  • Row-Level Security (RLS) in Supabase enforces access.

Retention Limits:

  • Active learners: data retained indefinitely for progress tracking.

  • Inactive accounts: anonymize after 2 years of inactivity (configurable).

  • Deleted accounts: data purged within 30 days (except legal retention requirements).

6.2 What Developers Can and Cannot Do

✅ Allowed:

  • Query production data for debugging (with proper access, in secure environment).

  • Use anonymized/synthetic data for local development.

  • Export aggregated analytics (no individual names).

❌ Prohibited:

  • Screenshot learner dashboards with names/emails for presentations.

  • Share quiz scores in Slack.

  • Copy production database to personal machine.

  • Demo live admin panel to external parties without masking data.

6.3 Data Breach Response

If You Discover a Breach (accidental exposure, leaked credentials, unauthorized access):

  1. Immediate (within 1 hour):

    • Stop the leak (revoke key, shut down service, etc.).

    • Notify Yza via call + #dev-alerts.

    • Document what was exposed, when, and how.

  2. Within 24 hours:

    • Tech lead assesses impact (how many users affected, what data exposed).

    • If >1000 users or sensitive PII: prepare NPC (National Privacy Commission) report.

    • Begin containment (reset passwords, audit logs, patch vulnerability).

  3. Within 72 hours:

    • Notify affected users (if breach is significant).

    • Submit NPC breach report (if legally required).

    • Publish incident post-mortem internally (what happened, how we'll prevent it).

Penalties for Hiding a Breach:

  • Legal: criminal liability under RA 10173.

  • Professional: termination of contract.

  • Ethical: you put thousands of learners at risk.

7. ACCEPTABLE USE OF GITHUB

7.1 Permitted Activities

  • Cloning repos to local machine for development.

  • Creating feature branches for assigned tasks.

  • Opening pull requests for code review.

  • Reviewing peers' code with constructive feedback.

  • Accessing public GitHub resources (docs, open-source libraries).

  • Forking open-source projects for learning (personal repos).

7.2 Prohibited Activities

  • Code Theft: Copying WyzLab code to personal repos or external projects.

  • Credential Sharing: Giving your GitHub account to others.

  • Unauthorized Repos: Creating public repos under wyzlab org without approval.

  • Malicious Commits: Introducing backdoors, malware, or intentionally broken code.

  • Bypassing Reviews: Force-pushing to protected branches.

  • Harassment: Using GitHub issues/PRs to harass or insult team members.

7.3 Personal Use of GitHub

You can:

  • Maintain personal repos for side projects.

  • Contribute to open-source projects (encouraged!).

  • Showcase WyzLab work in portfolio after internship ends and with approval.

You cannot:

  • Use WyzLab's GitHub Actions minutes for personal projects.

  • Clone WyzLab repos to personal accounts.

  • Share WyzLab code snippets publicly without redacting proprietary logic.

8. MONITORING AND AUDITS

8.1 What We Monitor

  • GitHub Activity:

    • Commits, PR approvals, branch deletions.

    • Access logs (who viewed/cloned repos).

    • Secret scanning alerts (if API key detected in commit).

  • Code Quality:

    • Linting, TypeScript errors, test coverage.

    • Security vulnerabilities (via Dependabot, Snyk).

  • Compliance:

    • Quarterly audits of data access logs.

    • Annual security assessment by external firm.

8.2 What We Don't Monitor

  • Personal GitHub repos.

  • Private DMs in Slack (unless reported for abuse).

  • Your screen during work hours (we trust you).

8.3 Audit Triggers

  • Suspected data breach or policy violation.

  • Mass deletion of code or repos.

  • Unusual access patterns (e.g., cloning all repos at 3 AM).

  • Complaints from team members or users.

If You're Audited:

  • Cooperate fully; provide access logs if requested.

  • If innocent, audit clears your name.

  • If violation found: corrective action (training, warning, termination depending on severity).

9. TRAINING AND AWARENESS

9.1 Onboarding Requirements

Every new developer must:

  • Read this policy.

  • Complete Data Privacy & Security Quiz (3 scenarios).

  • Sign Data Privacy Commitment Acknowledgment.

  • Confirm understanding of GitHub security rules.

9.2 Ongoing Training

  • Quarterly Security Briefings: New threats, updated policies.

  • Incident Reviews: Post-mortems shared (anonymized) for learning.

  • Guest Speakers: Cybersecurity experts, legal counsel on RA 10173.

9.3 Certification (Optional but Encouraged)

  • National Privacy Commission Data Protection Officer (DPO) training.

  • GitHub Security Best Practices (free course).

  • OWASP Top 10 awareness (for backend devs).

10. CONSEQUENCES OF POLICY VIOLATIONS

10.1 Violation Categories

Minor (First Offense, No Harm Done):

  • Example: Committed .env.local but caught in PR review before merge.

  • Action: Verbal warning, mandatory re-training.

Moderate (Repeated or Careless):

  • Example: Shared screenshot with learner names in team Slack.

  • Action: Written warning, supervised access for 30 days.

Severe (Intentional or High Impact):

  • Example: Leaked API keys publicly; stole code for personal project.

  • Action: Immediate termination, legal action if applicable.

Criminal (RA 10173 Violations):

  • Example: Sold learner data to third party; intentionally caused data breach.

  • Action: Report to NPC and law enforcement, criminal prosecution.

10.2 Appeals Process

If you believe a violation is wrongly attributed:

  1. Submit written appeal to Yza within 5 business days.

  2. Include evidence (logs, screenshots, witness statements).

  3. Independent review by tech lead + external advisor.

  4. Decision final within 10 business days.

11. ROLES AND RESPONSIBILITIES

Role

Responsibilities

CEO (Yza)

Policy approval, breach escalation, legal liaison

Admin/Finance (GeeLenn)

Contract compliance, NPC reporting, audit coordination

Tech Lead

Code review enforcement, access control, incident response

Developers (All)

Follow policy, report issues, protect data, write secure code

QA/Testers

Test with synthetic data, flag security bugs, verify privacy controls

12. POLICY REVIEW AND UPDATES

  • Frequency: Reviewed annually (January) or after major incident.

  • Changes: Announced in #general Slack, updated in Google Drive + WyzQuests.

  • Acknowledgment: All team members must re-sign after major updates.

13. RELATED POLICIES AND RESOURCES

  • Employee Handbook (general conduct, work hours, benefits)

  • Intellectual Property Agreement (code ownership, patents)

  • Remote Work Policy (workspace security, VPN use)

  • Incident Response Plan (detailed breach protocols)

External Resources:

14. CONTACT INFORMATION

For Policy Questions:

For Security Incidents (Urgent):

For Data Subject Requests (Learners):

Written by Yza Last updated January 12, 2026
Was this article helpful?