Internal Security & Data Handling Policy

Document ID: WBL-INT-SEC-v1.0 Classification: Internal — All Team Members Version: 1.0 Effective Date: [DATE] Owner: [Managing Director / CISO / Technical Lead] Next Review: [DATE + 12 MONTHS]

Purpose: This policy governs how Webility team members handle credentials, client data, personal data, and internal systems security. It complements the Code of Conduct (WBL-INT-COC-v1.0) and the AI Use Policy (WBL-POL-AI-v1.0).

Security failures at an agency are not just internal problems — they directly harm clients. A credential breach, a data leak, or unauthorized system access can cause a client data breach, legal liability, and irreparable trust damage. We take this seriously.

1. Password and Credential Policy

1.1 Password Standards

All passwords used for work systems must meet the following minimum requirements:

Never acceptable:

• Passwords based on names, birthdays, company names, or dictionary words
• Short passwords for "unimportant" systems (there are no unimportant systems)
• Writing passwords in a notebook, document, Slack, email, or spreadsheet
• Reusing any Webility system password for personal accounts

1.2 Two-Factor Authentication (2FA)

2FA is mandatory for all of the following:

• All client access accounts (CMS, hosting, analytics, CRM, etc.)
• All internal Webility systems (email, project management, file storage, secrets manager)
• All cloud hosting platforms (AWS, GCP, Azure, Vercel, Netlify, DigitalOcean, etc.)
• All communication tools (Slack, email, Teams)
• All financial accounts

Acceptable 2FA methods (in order of preference):

1. Hardware security key (FIDO2/WebAuthn — e.g., YubiKey) — required for critical systems
2. Authenticator app (Google Authenticator, Authy, 1Password) — standard for most systems
3. SMS — only if no other method is available; document and escalate to upgrade

SMS 2FA is a last resort only. SIM-swap attacks are a known threat. If a system only offers SMS 2FA, document this as a security risk and notify the Managing Director.

1.3 Secrets Manager

Webility uses [SECRETS MANAGER NAME] as the official vault for all credentials.

Requirements:

• Every project has a dedicated vault in the secrets manager
• Access to a project vault is restricted to personnel actively assigned to that project
• The PM is responsible for provisioning and deprovisioning access for each project
• Credentials must be moved to the vault immediately upon receipt — never stored elsewhere, even temporarily
• The vault must be reviewed and outdated credentials removed at project close

Vault structure:

Webility Vaults/
  ├── [CLIENT NAME - PROJECT CODE]/
  │   ├── Domain & DNS
  │   ├── Hosting & Server
  │   ├── CMS / Website Admin
  │   ├── Analytics & SEO Tools
  │   ├── Third-Party Integrations
  │   └── Internal Project Keys (API keys, etc.)
  └── Internal/
      ├── Webility Tools & Subscriptions
      └── Infrastructure

2. Credential Handling

2.1 Receiving Client Credentials

Approved methods for receiving credentials from clients:

If a client sends credentials by email or chat:

1. Do not store or use the credentials
2. Immediately reply: "For security, please don't send credentials by email. I'll send you a secure link to share them safely."
3. Send the secure link from the secrets manager
4. Once received securely, reply to the email or message: "Thank you — received securely. Please delete this message from your sent items and inbox."
5. Log the incident in the project notes (not a formal breach — but worth tracking)

2.2 Sharing Credentials Internally

• Share credentials with colleagues only via the project vault — never by Slack, email, or chat
• Grant vault access only to personnel actively assigned to the project
• When a team member leaves a project, revoke their vault access within [1] business day

2.3 Using Client Credentials

• Access client systems only for legitimate project tasks
• Do not use a client's credentials to create personal accounts on their platforms
• Do not leave yourself "backdoor" access after a project closes
• Do not share client access with subcontractors without the PM's written approval and a signed subcontractor agreement with appropriate confidentiality terms

2.4 Credential Handover at Project Close

At project close, the following must happen:

3. Device Security

3.1 Work Devices

All team members are responsible for the security of devices used for work:

3.2 Personal Devices

If using a personal device for work:

• All work communication and files must be accessed through company-approved apps, not personal apps (e.g., work email through the approved client, not a personal Gmail app)
• No client credentials or files may be stored locally on a personal device
• Same screen lock and encryption requirements as above apply

3.3 Public and Untrusted Networks

When working from a café, hotel, co-working space, or other untrusted network:

• Always use the Webility VPN before accessing any client systems, internal systems, or work email
• Do not access client admin areas, secrets manager, or banking on a network you don't control

4. Client Data Handling

4.1 Data Minimization

The minimum exposure principle applies to all client data:

• Access only the data you need to complete the specific task
• Do not request access to data beyond the scope of your project role
• Do not export or download entire databases for inspection — use targeted queries
• If you need to analyze a large dataset, use anonymized or sample data wherever possible

4.2 Local Storage of Client Data

• Do not store client personal data on personal devices — only on work devices, and only temporarily while actively working
• Do not store client data in personal cloud accounts (personal Google Drive, personal Dropbox, personal iCloud)
• Temporary local copies of client data must be deleted within [24] hours of completing the task that required them
• Raw database exports containing personal data must be stored in the project vault or encrypted project folder — never in a general-purpose Slack channel, email, or shared drive without access controls

4.3 Personal Data in Development

When building or testing a system that processes personal data:

• Never use real production personal data in development or staging environments
• Use anonymized, synthetic, or masked data for testing
• If real data is needed for debugging a production issue, obtain explicit PM and client approval, access only what is necessary, and delete it immediately after use

4.4 Sub-Processors and Third-Party Tools

When introducing a third-party tool that will process client personal data:

1. Identify whether the tool processes personal data (data flows through their servers, not just your device)
2. Review the tool's privacy policy and data processing terms
3. Confirm the tool is on the approved tool list (see Section 4.5) or submit for approval
4. If client has a DPA in place, confirm the new tool is listed or added as a sub-processor

4.5 Approved Tool List

Adding a new tool: Submit a request to [MANAGING DIRECTOR / TECHNICAL LEAD] with: tool name, purpose, data types that will flow through it, and their privacy/security documentation. Approval required before use.

5. Incident Response

5.1 What Constitutes a Security Incident

Report any of the following immediately to the Managing Director:

5.2 Incident Response Steps

Step 1 — Contain (Immediate)

• Do not attempt to "fix" the issue yourself before reporting
• If it's a credential compromise: change all affected passwords immediately
• If it's a device: remotely lock or wipe the device (contact IT)
• If it's a system: take screenshots, isolate if possible, do not delete logs

Step 2 — Report (Within 1 Hour)

• Notify the Managing Director immediately by phone if severe; within 1 hour by message otherwise
• Do not disclose the incident to the client without the Managing Director's authorization
• Provide: what happened, when, what data is involved, what you've done so far

Step 3 — Assess (Managing Director-led)

• Managing Director determines scope and severity
• Legal counsel engaged if personal data may be involved
• Client notification decision made (required within 72 hours for GDPR/Law 25 personal data breaches)

Step 4 — Remediate

• Technical fix implemented
• Affected credentials rotated
• Client notified per Step 3 decision
• Incident documented

Step 5 — Review

• Post-incident review within [5] business days
• What happened, root cause, what we changed

5.3 Breach Notification Obligations

If the incident involves personal data that may trigger regulatory notification:

Notification handling is always managed by the Managing Director and/or legal counsel — never by a PM or developer acting independently.

6. Access Management

6.1 Onboarding — New Team Members

When a new employee or contractor joins a project:

• Create accounts on only the tools they need for their role
• Add to project vault with minimum necessary access
• Assign to project in the project management tool
• Issue this security policy and obtain signed acknowledgement
• Confirm 2FA is enabled on all accounts before they begin work

6.2 Offboarding — Team Members Leaving

When a team member leaves Webility (or leaves a project):

The PM is responsible for initiating Steps 1–4 for project-specific access. Managing Director is responsible for Steps 5–7.

6.3 Principle of Least Privilege

Assign the minimum permission level required for a task. Examples:

Review and reduce access levels after each project phase.

7. Acknowledgement

All team members must acknowledge this policy upon joining Webility and upon any material update.

Team Member:

I confirm that I have read, understood, and agree to comply with this Security & Data Handling Policy.

Name: ___________________________ Signature: ___________________________ Date: ___________________________ Role: ___________________________

Webility — WBL-INT-SEC-v1.0 | Internal Security & Data Handling Policy Internal document — not for client distribution. Last reviewed: [DATE]. Next review: [DATE + 12 MONTHS].