Policy 13 Confidentiality and Information Classification
Owner Security Lead and information owners | Applies to all personnel and approved recipients | Access internal
Classification and permitted use
Information is classified as Public, Internal, Confidential or Restricted. Public information has been approved for release. Internal information supports ordinary operations and is not for public circulation. Confidential information includes proposals, commercial terms, unpublished work, client lists and non-public project records. Restricted information includes passwords, tokens, bank access, identity documents, medical information, disciplinary files and sensitive client datasets. If uncertain, treat non-public information as Confidential until the owner decides.
Access is granted for a specific business purpose and does not authorise copying, reuse or disclosure for personal benefit. Confidentiality applies to conversations, screenshots, recordings, printed material, code, prompts, reports and metadata as well as formal documents. Information remains protected when a project ends or a person leaves.
Handling rules
Store information in the approved workspace for the correct client. Share only with verified recipients who need it and are authorised to receive it. Check email recipients, attachments and sharing permissions before sending. Use approved secure transfer for Restricted data; do not place secrets in chat, public repositories or unprotected spreadsheets. Lock screens and secure paper files when unattended. Avoid confidential discussions where others can overhear.
Personnel must not publish work samples, client identities, revenue figures, payroll data or internal screenshots without the required written approval. Removing a name may not adequately anonymise information if other details identify the person or client. Use synthetic or properly de-identified information for training and demonstrations whenever possible.
Exceptions and lawful disclosures
Confidentiality does not cover information lawfully public without a breach, independently developed without protected material, or lawfully received without restriction. Personnel may obtain confidential legal advice and make protected disclosures to competent authorities. If legally compelled to disclose company or client material, involve the authorised contact where lawful, limit disclosure to what is required and preserve the request. Prior company approval is not required where it would unlawfully obstruct reporting.
Responsibilities and incidents
Information owners set access and handling requirements. Managers explain client-specific restrictions before work begins. Personnel must report misdirected messages, exposed links, lost papers or suspected misuse immediately under Policy 20, even if they caused the error. The company records recipient commitments, approvals and incidents. NDA obligations must be signed where appropriate; this policy alone does not replace an enforceable individual agreement.
Policy 14 Access Control and Account Security
Owner Security Lead | Applies to all company and client systems | Access internal
Account approval
Every account requires a named user, business owner, purpose, access level and approval. Shared human logins should be avoided; where unavoidable, use controlled access with attributable activity and a recorded exception. Service accounts must have an owner and a limited purpose. Interns receive supervised, time-limited access and should use test environments rather than production data where possible.
Access follows the least privilege principle: grant only what the role needs, for the necessary period. Finance records, HR files, client databases and hosting administration must not be visible company-wide. Administrative and ordinary user access should be separate where the system permits. High-risk actions require additional approval or review.
Authentication and secrets
Use unique strong passwords stored in an approved password manager. Enable MFA for email, hosting, domains, repositories, financial systems and other supported business accounts. Do not share OTPs, recovery codes, tokens or private keys through ordinary messages. Company account recovery must remain under approved company control with an authorised backup custodian.
Never commit credentials to source code or place them in client-side applications, documents or tickets. Use approved secret storage and scoped credentials. Rotate secrets promptly after suspected exposure, departure of a person who knew a shared secret, or other risk trigger. A routine password change alone does not resolve a stolen active session or compromised recovery method.
Reviews and changes
The system owner reviews privileged access at least monthly and other access at least quarterly under the company access-review procedure. Review access immediately on a role change, project end or departure. Record who approved, changed and checked access. Temporary access must expire or be reviewed at the stated end date.
Emergency access
Emergency access is time-limited, logged and used only to protect or restore authorised services. The person invoking it records the reason and actions; a separate authorised person reviews use afterward. Security must promptly revoke unnecessary access and preserve logs after an incident. Personnel must report unexpected MFA requests or access they do not need instead of exploring other clients' or employees' information.
Policy 15 Acceptable Use of Company Systems
Owner Security Lead and department heads | Applies to systems users | Access internal
Authorised use
Company email, CRM, hosting, repositories, portals, devices and subscriptions are provided for approved work. Limited personal use may be permitted by management if lawful, modest and consistent with security and work responsibilities. It must not incur material cost, expose confidential information or create an expectation that company systems are private personal storage.
Prohibited activity
Personnel must not bypass access controls, scan systems without permission, install pirated software, run unapproved remote-access tools, mine cryptocurrency, distribute malicious code, use business accounts for fraud or harassment, or download unlawful material. They must not create hidden administrator accounts, disable security logging, alter evidence or use another person's credentials. Authorised testing must have a written scope and permission from the asset owner.
Use approved software and extensions. Requests for new tools must identify purpose, cost, permissions and data handled. Security assesses risk before installation or integration. A free tool still requires review if it accesses client files, browser sessions, mail or credentials. Company software licences may not be transferred to personal businesses or shared beyond the licence terms.
Email browsing and integrations
Check suspicious links, unexpected attachments and requests for payment or credentials. Verify unusual instructions through an independent trusted channel. Do not automatically forward business email to a personal account. OAuth connections, browser extensions and automation integrations must use only the permissions needed and must be removed when no longer required.
Records monitoring and enforcement
Business records must remain in approved systems. Personnel may not erase or export records to conceal conduct or prepare unauthorised private work. Monitoring is limited by Policy 23 and applicable law. Security may isolate a compromised device or account to protect systems, while HR handles any conduct concerns fairly. Exceptions require a documented purpose, controls, approver and expiry date; an exception cannot authorise unlawful activity or violate a client contract.
Policy 16 Personal Devices and Remote Security
Owner Security Lead | Applies to approved personal and remote devices | Access internal
Approval and minimum controls
A personal device may access company or client systems only after approval for the data involved. The device must have a supported operating system, timely security updates, screen lock, appropriate malware protection and encryption where required by the data risk. Rooted, jailbroken or unsupported devices must not handle Restricted information without an exceptional documented assessment.
Work accounts should be separated from personal accounts through a managed profile, browser profile or approved equivalent. Household members and other unauthorised people must not access work sessions or files. Disable automatic personal-cloud backup of work data. Use secure networks and the approved VPN or remote-access method when required; do not assume public Wi-Fi is safe because it requires a password.
Storage and physical security
Prefer browser-based or managed access that avoids local downloads. Any permitted local copy must be minimised, encrypted and deleted when no longer needed. Do not leave devices unattended in public places or vehicles. Printing Restricted material remotely requires explicit approval and a secure disposal method. Screen-sharing must be limited to the intended window and checked for notifications or unrelated client material.
Support and privacy boundaries
Before enrolling a personal device, explain what management software can see, enforce or remove. Record the user's informed agreement where required. Company access should be limited to business data and relevant security information. Full-device remote wiping is not a default right. Use selective removal where feasible; any broader action requires a clear legal basis, prior notice and appropriate authorisation.
Incidents and exit
Immediately report loss, theft, malware, unauthorised household access or accidental synchronisation. Do not conceal an incident to avoid responsibility. Security determines isolation, token revocation, credential rotation and other containment. At exit or withdrawal of permission, remove work profiles and data through a documented process and confirm completion. HR and Security must preserve relevant evidence and avoid deleting unrelated personal material. Costs, repairs and reimbursement arrangements belong in the individual device agreement.
Policy 17 Client Data Handling and Secure File Sharing
Owner Operations and Security Lead | Applies to all client projects | Access internal
Approved instructions and collection
Use client data only for the contracted task and documented instructions. Collect only what is necessary. Before accepting highly sensitive records, determine the data type, legal and contractual obligations, approved storage, access and deletion arrangements. Staff must not collect full payment-card credentials, identity documents or health records simply because a client sends them without first assessing the need and safeguards.
Segregation and sharing
Each client has a separate approved workspace with named access. Avoid mixed-client folders and shared export files. External sharing should be restricted to named recipients, with expiry where available. Public links require explicit approval and must never be used for Restricted data. Verify recipient addresses and permissions before release; test links with the intended access level when practical.
Personal email, private cloud drives and messaging apps are not approved by default. A client asking to use a channel does not remove the need for company security approval. Where a messaging service is approved for routine coordination, sensitive attachments and credentials must still use the approved secure method. Keep material approvals and instructions in the project record.
Development testing and subcontractors
Use synthetic data in development, demonstrations and training where feasible. Production extracts require an approved purpose, minimisation, protection and deletion date. Do not send client information to an AI provider, freelancer, translator or other vendor without the necessary authorisation and contractual safeguards. Client-specific restrictions on country, personnel or subprocessors must be checked before access is granted.
Requests return and deletion
Forward requests for access, correction, export or deletion to the responsible owner; staff must not independently disclose an entire database or delete records. Verify identity and authority proportionately and preserve third-party confidentiality. At completion, return or delete data according to the agreement and retention schedule, recording backups and legal holds separately. A disclosure error triggers Policy 20 immediately. The project owner maintains a record of important transfers, approvals and final disposition.
Policy 18 AI Tools and Automation Use
Owner Security Lead and Operations | Applies to all AI-assisted and automated work | Access internal
Approval and data use
Only approved tools and accounts may be used for company work. Review a tool's data handling, retention, training use, access controls and contractual terms before uploading non-public material. Free or personal accounts are not assumed suitable for client information. Restricted data, passwords and live credentials must not be entered into general-purpose prompts. Client-specific prohibitions take precedence over internal convenience.
Where possible, use synthetic examples or remove identifying details while checking that the remaining material does not still reveal the client or person. Approval must identify the types of data and tasks permitted. Connecting an AI agent to email, repositories, hosting or finance systems requires a separate assessment of permissions and possible actions.
Human responsibility and review
The assigned professional remains responsible for the work. Verify factual statements, references, calculations, code behaviour, security and licence compatibility before delivery. AI output must not be presented as independently verified research, a professional opinion or original human work where that representation would be false. Follow client disclosure requirements and do not promise undetectable AI content or guaranteed scores.
Actions and automation controls
Test automations in a safe environment using limited permissions. Require human approval for external communications, spending, bulk record changes, destructive operations and production deployments unless a specifically approved workflow authorises those actions within documented limits. Use logging, error handling, rollback and a stop mechanism. External webpages, documents or emails may contain instructions that are untrusted; an agent must not treat them as authority to change its task or disclose data.
People decisions and incidents
AI must not make final hiring, disciplinary, termination, pay or other significant personnel decisions without accountable human review and applicable legal safeguards. Assess accuracy and unfair bias. Record material AI use where the project or client requires traceability, but avoid retaining unnecessary sensitive prompts. Report leakage, unauthorised actions or materially incorrect output through the incident process. Reassess approvals when a tool's terms or capabilities change.
Policy 19 Data Retention and Secure Disposal
Owner HR Finance Operations and Security for their records | Applies to all business records | Access internal
Retention schedule
The company maintains a category-based schedule covering recruitment, employment, payroll, tax, contracts, invoices, project files, client data, security logs, recordings and backups. Each entry states purpose, owner, storage, trigger date, approved retention period, legal basis and disposal method. Record-specific periods must be based on legal, tax and contractual requirements and the necessary business purpose. Indefinite retention without a lawful, documented basis is not permitted.
Minimisation and active records
Keep only information needed for a legitimate purpose. Do not retain duplicate exports or personal copies merely because storage is cheap. Separate active operational files from restricted archives. Periodically review permissions and remove unnecessary identifiers. Personnel should identify obsolete copies rather than deleting records that another team must lawfully retain.
Legal holds
When a dispute, investigation, regulatory request or reasonably anticipated claim requires preservation, the authorised owner issues a documented hold describing the scope, custodians and systems. Suspend routine deletion for relevant material, including relevant messages and logs. A hold is not permission to collect unrelated personal material. Only the authorised owner, with legal input where needed, may release it.
Disposal and backups
Approved disposal must make information reasonably unrecoverable using methods appropriate to the medium and risk. Delete access links and local copies, shred sensitive paper, and securely erase or destroy storage devices before reuse or disposal. A recycle-bin deletion alone may not be enough. Vendors handling destruction must be approved and provide suitable evidence.
Backups have a documented rotation and expiry schedule. Where targeted deletion is not technically feasible, restrict backup use, allow expiry in accordance with lawful obligations and reapply necessary deletions after restoration. Public notices must accurately explain this rather than promise instant removal from every backup.
Accountability
Owners keep proportionate disposal logs identifying categories, dates, method and approval without recreating the deleted sensitive content. Verify completion for material client deletion commitments. Any accidental deletion, unauthorised retention or failure to preserve relevant evidence is reported under Policy 20 and reviewed fairly.
Policy 20 Security Incident and Data Breach Response
Owner Security Lead with management and contract owners | Applies to all personnel | Access internal with restricted response details
Reporting and triage
Report suspected account compromise, lost devices, exposed credentials, ransomware, misdirected files, unauthorised exports, data loss or suspicious system changes immediately through ataraxydevelopers@gmail.com. Do not wait to prove a breach. Give the time, systems, data involved, observed behaviour and actions already taken. If the normal channel may be compromised, use the verified alternative contact.
The incident lead assigns an incident record, severity, owner and response team. Assess ongoing harm, affected clients, personal data, availability and legal or contractual notification duties. Record the time the company became aware and the basis for each decision. Internal reporting targets do not replace external legal deadlines.
Containment and evidence
Take proportionate steps to stop harm, such as revoking sessions, disabling a public link, isolating a device or pausing an integration. Preserve logs and relevant evidence before destructive remediation where feasible. Do not wipe a device, delete messages, negotiate with an attacker or contact affected clients independently. Avoid investigating beyond authorised systems or accessing unnecessary personal information.
Assessment and communication
Determine what happened, whether access or extraction occurred, affected categories and numbers where known, likely consequences and protective measures. Distinguish confirmed facts from estimates. Management, legal counsel and the contract owner decide notifications to clients, affected people, regulators, insurers and authorities. No universal notification period is assumed; use the applicable law and contract, including earlier processor-to-client requirements.
External messages must be accurate, approved and updated when facts change. Do not promise that no data was accessed merely because there is no evidence yet. Staff must preserve confidentiality without obstructing lawful reporting.
Recovery and improvement
Remove the cause, patch weaknesses, rotate compromised secrets and validate restored services before returning to operation. Monitor for recurrence and notify clients of relevant recovery limitations. Conduct a lessons-learned review documenting root causes, control gaps, responsible owners and due dates. Close the incident only after necessary actions and communications are tracked. Honest rapid reporting is encouraged; any misconduct assessment is separate from technical containment.
Policy 21 Backups Recovery and Business Continuity
Owner Security Lead and Operations | Applies to critical systems and client services | Access internal
System inventory and recovery requirements
Maintain an inventory of domains, hosting accounts, databases, repositories, email, CRMs, finance records and key vendors. Identify the business owner, administrator, backup method and recovery dependencies. Set a recovery point objective, meaning acceptable data loss, and recovery time objective, meaning target restoration time, for each critical service. These are internal targets unless expressly agreed with a client.
Backup design
Back up the components needed for a working recovery: code, databases, uploaded files, configuration, necessary keys and documented dependencies. Git repositories alone do not provide a complete database or hosting backup. Keep at least one protected copy separate from the primary provider or account where practical. Encrypt sensitive backups and restrict deletion and administration rights. Never commit plaintext secrets or unrestricted client databases into a repository as a backup shortcut.
Document frequency, retention and location based on risk and the client agreement. Automated jobs require failure alerts and a responsible person to investigate them. Provider-managed backups must be understood, including exclusions, retention and account-loss limitations; a plan advertisement is not proof of a recoverable backup.
Testing and recovery
Test sample restores regularly and after material infrastructure changes. Perform a documented restore exercise at least quarterly for critical services, with more frequent tests where risk warrants. Test database integrity, application operation, permissions and available recovery credentials. Record results, elapsed time and fixes. A successful backup job is not sufficient evidence of successful restoration.
Continuity and communication
Assign a backup administrator and ensure critical recovery information can be accessed through controlled emergency arrangements if a key person is absent. Maintain outage communication templates, client contacts and alternatives for urgent work. During disruption, prioritise safety, confidentiality and critical commitments. Do not guarantee zero downtime or zero data loss without a validated and contracted service level. Review the plan after outages and material changes.
Policy 22 Intellectual Property and Software Licensing
Owner Operations with legal review | Applies to all creators and project owners | Access internal
Ownership documentation
Before work begins, record the ownership and licence terms in the employment, contractor or client agreement. The policy does not itself cure a missing assignment. Work created for a project must be identified and delivered through approved systems. Pre-existing tools, templates, libraries, personal works and third-party assets should be disclosed and separated from newly commissioned deliverables.
The company must obtain rights sufficient to meet its client commitments. Do not promise exclusive ownership of third-party software, stock media, fonts or AI output where those rights cannot be granted. Transfer timing, including any payment condition, must be expressly stated in the client agreement. Client data remains subject to the client's rights and must not be treated as company-owned merely because it is stored in company systems.
Third-party and open-source materials
Use only assets and software with a valid licence for the intended use. Record sources, licence versions, notices and restrictions. Review open-source obligations, including attribution, redistribution and source disclosure where relevant, before incorporating components. Copying code from another client's private project or lifting protected website text is prohibited without authority, even if technically easy or requested informally.
Creation and delivery
Writers and developers must disclose material borrowed content, dependencies and contributors. Keep source files, project history and appropriate evidence of creation. Use approved repositories and avoid storing the only copy in a personal account. Do not release client deliverables publicly or submit them to a portfolio without Policy 29 approval.
Claims and departures
Report suspected infringement or ownership disputes promptly. Preserve the disputed material and provenance; do not admit liability, remove evidence or promise compensation without authority. The responsible owner assesses replacement, licensing or other remediation. At exit, personnel deliver authorised work and retain no unauthorised copies. Confidentiality and valid assignment obligations continue as agreed, while unrelated personal creations and lawful retained records remain protected.
Policy 23 Staff Privacy and Monitoring Notice
Owner HR and Security Lead | Applies to workers applicants and interns as relevant | Access staff portal
Information and purposes
Ataraxy may process identity and contact details, recruitment records, agreements, pay and bank information, attendance, leave, performance, training, access logs and necessary investigation records. HR must maintain an accurate inventory and an approved retention schedule for these records. Information is used to administer work, meet legal duties, protect systems, pay personnel and investigate legitimate concerns. Additional uses require assessment and appropriate notice.
Monitoring disclosures
Before deployment, identify each monitoring method, its purpose, data collected, frequency, access and retention. This may include login logs, business-system audit trails, office CCTV or an approved time-recording tool if actually used. This policy does not authorise undisclosed keylogging, continuous screenshots, always-on cameras, personal-account access or monitoring of unrelated personal devices and communications.
Monitoring must be necessary, proportionate, lawful and appropriately notified. CCTV must not cover private areas. Access to business email or device content for an investigation requires documented authority and a defined scope. Covert monitoring requires separate legal review and cannot be justified merely by this handbook.
Sharing and safeguards
Only authorised HR, Finance, management and service providers receive information needed for their role. Clients receive relevant assignment details, not unrestricted personnel files. Universities receive necessary placement records under Policy 34. Cross-border access and vendors must be assessed. Apply access controls, secure transfer and retention limits appropriate to the information.
Requests and consent
Personnel may contact ataraxydevelopers@gmail.com to ask about processing, request correction and exercise applicable rights. Verify identity proportionately and respond within the applicable deadline. Explain lawful retention limits where deletion cannot be granted. Consent is not treated as a universal basis for all employment processing or as a waiver of rights. Where consent is relied on, it must meet the applicable requirements and withdrawal arrangements must be explained.
Updates and concerns
HR provides the current notice at onboarding and before material new monitoring begins. Personnel may raise privacy concerns without retaliation. Suspected unauthorised access to personnel data follows Policy 20. The public website privacy notice does not replace this more specific staff notice.
