Data Protection & Security Policy

1. Purpose and risk-based approach

This Policy describes the baseline administrative, technical and organizational practices Woodlentra Studio uses to protect information handled through its website and professional services. Controls are selected according to the nature of the engagement, the sensitivity and volume of information, the systems involved, the client’s instructions, available technology and the reasonably foreseeable risk.

This Policy is not a certification, independent audit report or guarantee against every incident. Project-specific requirements, including regulated-data obligations, must be identified before work begins and documented in the applicable agreement, security schedule or data-processing terms.

2. Data minimization and classification

Woodlentra Studio seeks to receive only information reasonably necessary for inquiry review, contracting, delivery, support and legal recordkeeping. General forms must not be used to send passwords, private keys, production databases, payment-card data, health information or other highly sensitive records.

Information is considered according to practical categories such as public, internal business, confidential project and restricted credential or regulated data. More sensitive categories require narrower access, approved transfer methods and shorter working retention where feasible.

3. Roles and responsibility

For ordinary business contact information, Woodlentra Studio determines the purpose and means of processing. For personal data contained in a client-controlled product or dataset and handled only to perform documented services, the client generally determines purpose and means, and Woodlentra Studio acts in a service-provider or processor capacity to the extent applicable.

The client remains responsible for lawful collection, notices, user permissions, retention instructions, data-subject response decisions and the legality of the systems and content it supplies. Roles may be clarified in a project-specific data-processing agreement.

4. Access control

Access to business and project systems is limited to personnel and approved specialists with a legitimate need. Practices may include unique accounts, role-based permissions, least privilege, multi-factor authentication, periodic access review and prompt removal of access that is no longer required. Shared credentials are avoided where an individual account is available.

Client accounts should remain client-owned whenever practical. Woodlentra Studio should receive delegated access rather than ownership transfer. The client must maintain accurate administrators and recovery methods for its systems.

5. Credential handling

Credentials, tokens, certificates, secrets and private keys should be exchanged through an approved secure method rather than ordinary email or website forms. Secrets should not be placed in source code, design files, screenshots, tickets or public repositories. Environment variables, secret managers or provider credential stores are used where supported and appropriate.

Temporary credentials should be scoped, time-limited and revoked after use. The client should rotate credentials when personnel, providers or project phases change and after any suspected exposure.

6. Workstations and accounts

Workstations used for project activity should use supported software, device access controls, screen locking, security updates and anti-malware or platform security protections appropriate to the device. Business accounts should use strong unique authentication and multi-factor protection where available. Local storage of client data is minimized and protected according to risk.

7. Development and testing environments

Development, staging and production environments should be separated where project architecture permits. Production access is limited and documented. Real production data should not be used in development when synthetic, masked or minimized data can meet the purpose. Test accounts, debug modes and temporary access must be reviewed before release.

A client must identify business-critical environments and change-management requirements. Woodlentra Studio will not intentionally test destructive or intrusive behavior in production without explicit scope, authorization, rollback planning and coordination.

8. Secure development practices

Project controls may include peer or structured code review, dependency review, input validation, output encoding, authentication and authorization checks, secure transport, error-handling review, secret detection, automated testing, logging review and security scanning appropriate to the stack. Findings are prioritized according to likelihood, impact, exposure and available remediation.

Automated tools do not establish that software is secure. Secure development also depends on architecture, configuration, deployment, operational monitoring and timely maintenance after release.

9. Encryption and transmission

Encryption in transit is used where supported by the relevant provider and protocol. Encryption at rest depends on the hosting, device, repository, storage and database services selected for the engagement. The existence of encryption does not replace access control, key management, data minimization or secure endpoint practices.

Highly sensitive data requiring specialized key custody, hardware security modules, customer-managed encryption or sector-specific controls must be expressly scoped.

10. Repositories, backups and recovery

Source repositories should use controlled membership, branch protection or review processes appropriate to the project, and a documented ownership model. The client is responsible for maintaining independent business-continuity and production backups unless backup management is expressly included. A backup is not considered reliable solely because a provider advertises backup capability; retention, restoration access and recovery testing must be considered.

Woodlentra Studio may maintain working copies and repository history for delivery and recordkeeping. Final retention and transfer are governed by project documents.

11. Logging and monitoring

Systems may use logs to investigate errors, authenticate actions, measure performance and identify suspicious activity. Logging should avoid unnecessary secrets and sensitive payloads. Retention and access should reflect operational need and privacy impact. Monitoring scope, alert coverage and response hours are included only when expressly stated in the engagement.

12. Vendor and subprocessor management

Woodlentra Studio may use hosting, repository, communication, invoicing, storage, security and project-management providers. Selection considers capability, access needs, contractual terms, security features, data location where relevant and the sensitivity of information. No vendor review eliminates all risk, and provider practices may change.

Project-specific subprocessors or externally hosted tools may be identified in the applicable project records. The client should not assume a provider is included or approved for regulated data unless that use is documented.

13. Independent specialists

Where approved specialists support an engagement, they receive only the access and information reasonably necessary for their assigned work and are subject to confidentiality and security expectations appropriate to their role. The client will be informed when the agreement requires prior approval.

14. Security incidents

A suspected incident is evaluated to determine affected systems, information, scope, likely impact, containment needs and notification obligations. Reasonable steps may include revoking access, rotating secrets, preserving relevant logs, isolating systems, coordinating with providers, restoring from known-good state and documenting corrective actions.

Where Woodlentra Studio confirms a security incident affecting client data under its control, the client will be notified without undue delay consistent with accurate investigation, security and legal requirements. The notice will include information reasonably available at the time and may be updated. The client is responsible for regulatory and end-user notifications unless the agreement allocates another role.

15. Vulnerability reporting

A person who believes a Woodlentra Studio-controlled system contains a vulnerability should report it privately using the contact details below, with the affected location, reproduction steps, observed impact and contact information. Testing must not access another person’s data, disrupt service, use social engineering, create persistence, exfiltrate information or exceed authorization.

A report does not create a right to payment or public disclosure. Woodlentra Studio may coordinate remediation and request reasonable time before publication.

16. Retention, return and deletion

Business and project records are retained according to contractual, legal, accounting, dispute-management and operational needs. Working client data and credentials are returned, deleted, revoked or restricted when no longer required, subject to repository history, backups, legal holds and records that must be retained. Backup copies may age out through provider cycles rather than immediate selective deletion.

17. Client security responsibilities

The client must maintain lawful authority, accurate system inventories, backups, administrators, user access, endpoint security, incident contacts and prompt notice of relevant changes. The client must not provide restricted data without written approval or direct Woodlentra Studio to weaken controls, bypass provider terms or perform unauthorized testing.

After handover, the client is responsible for timely dependency updates, credential rotation, monitoring, content administration and operational security unless continuing services expressly include those tasks.

18. Exceptions and continuous improvement

A control may be adapted where technical constraints, client architecture or an emergency require another approach. Material exceptions should be documented with reason, duration, risk and compensating measures. Practices are reviewed as services, threats and tools evolve. The effective date identifies the current version of this Policy.