Security Policy

1. Our Security Commitment

Trixent Security provides offensive security assessments, vulnerability assessments and penetration testing (VAPT). During these engagements, clients may entrust us with vulnerability findings, system architecture, test credentials, technical evidence and other confidential information.

We are committed to handling such information responsibly, limiting access to authorized personnel, minimizing unnecessary data collection and protecting client information throughout the engagement lifecycle.

This policy describes our approach to protecting client engagement data. Specific contractual commitments and security requirements are governed by the applicable signed agreements.

2. Scope and Related Documents

This policy applies to information received or generated while performing authorized security engagements.

Personal information collected through our public website and enquiry forms is addressed separately in our Privacy Policy.

Depending on the engagement, this policy operates alongside:

• The signed statement of work (SOW), which defines the services and agreed deliverables.
• The Rules of Engagement (RoE), which define authorized targets, methods, timing and operational restrictions.
• The Non-Disclosure Agreement (NDA), where applicable.
• The Data Processing Agreement (DPA), where applicable to the processing of personal data.
• The applicable Terms and other signed contractual documents.

If provisions conflict, the applicable signed agreements govern according to their terms and precedence provisions. This public policy does not independently amend a signed agreement.

3. Roles and Authorization

Before testing begins, the client must have legal authority to authorize the proposed activities on the in-scope systems.

The client is responsible for obtaining any necessary permission from system owners, cloud providers, hosting providers or other third parties. Trixent Security will verify the authorization and scope information reasonably required for the engagement.

Our role in processing personal data depends on the actual services, instructions and applicable agreement. Where Trixent processes personal data on a client's behalf, the relevant DPA defines the parties' processing responsibilities. This does not mean that Trixent acts as a processor for every activity it performs.

Testing begins only after the required written authorization and engagement documentation are in place.

4. Authorization Before Testing

The signed engagement documentation must identify the authorized scope, targets, testing windows, permitted techniques, relevant source addresses and emergency contacts, as appropriate to the engagement.

We test only within the authorized scope. A finding or technical path that reaches an out-of-scope system does not extend our authorization.

When an out-of-scope asset or unexpected exposure is encountered, we stop the activity that could access or affect it, preserve only the minimum information necessary to describe the issue, and seek further written authorization before proceeding.

Changes to scope, testing windows, permitted techniques, report recipients or other material instructions must be approved through the engagement's documented change-control process. For sensitive changes, we may verify instructions through an independently established contact method.

Where a third party owns or controls an affected asset, testing will not proceed without the necessary authorization.

5. Engagement Data We Handle

Depending on the service and its scope, engagement information may include:

• Scope definitions, network details, architecture diagrams and client-provided documentation.
• Scan output, requests and responses, screenshots, notes and proof-of-concept material.
• Test accounts, temporary credentials and access tokens used during testing.
• Vulnerability findings, severity assessments, reports and retest results.
• Engagement correspondence, authorization records and relevant activity logs.

We aim to collect and retain only the information reasonably necessary to deliver the authorized service, substantiate findings and meet applicable contractual or legal obligations.

6. Secure Communication and Report Delivery

Clients should not submit passwords, private keys, API keys or other secrets through public website forms or ordinary unprotected email.

Before engagement work begins, the parties should agree on an appropriate method for exchanging sensitive information. Depending on the engagement, this may include access-controlled file transfer, encrypted storage or another mutually approved channel.

Reports and supporting evidence are confidential. We deliver them to recipients authorized under the engagement documentation and take reasonable steps to verify the recipient and restrict access.

Delivery controls may include encryption, access restrictions and expiring links where supported by the selected delivery method.

If credentials or other sensitive information are received through an inappropriate channel, we restrict access, notify the client as appropriate and coordinate any necessary containment or rotation. Copies are handled under the applicable retention and deletion process.

7. Access Control and Storage

We apply access restrictions intended to ensure that engagement data is available only to personnel who require it for their assigned responsibilities.

Our handling practices include the following safeguards, subject to the systems and arrangements used for the engagement:

• Least privilege: Access is limited to the information and systems required for the assigned role.
• Individual accounts: Access should be attributable to an individual rather than depend on shared credentials.
• Authentication: Multi-factor authentication is used on systems that support it and provide access to engagement information.
• Protected storage: Engagement data is kept in access-controlled locations rather than intentionally placed on public website infrastructure.
• Device protection: Devices used to store engagement data should use appropriate access controls, screen locking and device encryption.
• Separation: Engagement information is organized to reduce unnecessary access across clients and projects.

Access permissions are reviewed when responsibilities change and when access is no longer required.

If engagement data is inadvertently received through the general enquiry mailbox, we restrict access and transfer it to the appropriate engagement storage location where feasible. We then remove unnecessary accessible copies. Copies retained by email providers, archives or backups may require separate retention and deletion handling.

8. Personal Data and Secrets Found During Testing

We seek to demonstrate vulnerability impact without unnecessarily collecting real personal information, confidential business records or production data.

Where possible, we use synthetic indicators, minimal samples or appropriately redacted evidence. If a vulnerability exposes substantial personal or proprietary information, we pause the relevant activity, notify the client through the agreed channel and obtain instructions before proceeding further.

Secrets discovered during testing—including credentials, password hashes, API keys, private keys and session tokens—are handled as sensitive information. We restrict their use to the authorized assessment, redact them from reports where appropriate, notify the client when rotation or revocation is advisable, and remove retained copies under the engagement's cleanup procedures.

We do not reuse client secrets or retain extracted production data merely for convenience or future research.

9. Subcontractors and Sub-processors

Third parties performing testing activities are engaged only in accordance with the authorization and subcontracting requirements agreed with the client.

Where external service providers process engagement data, their use is subject to the applicable contractual requirements and the safeguards appropriate to the information involved.

Where a DPA applies, sub-processor appointments, relevant processing locations, notice requirements and objection rights are governed by that agreement.

We do not imply that all providers are located in a particular country or that every provider is used for every engagement. Relevant provider details should be recorded in the applicable contractual or processing documentation where required.

10. Retention and Destruction

Engagement information is retained according to its type, the needs of the authorized work, the applicable agreements and any legal retention obligations.

Unless a signed agreement specifies a different schedule, the following is the proposed baseline:

• Credentials and test accounts: Access is disabled or credentials are removed from systems under our control when no longer required, subject to the engagement's cleanup process. Clients remain responsible for revoking accounts and credentials they control.
• Raw testing artifacts: Scan output, captures and proof-of-concept material are deleted within 30 days after final report delivery. Where an agreed retest requires retaining specific evidence, that limited material may be retained until the retest is completed and then deleted within 30 days, subject to any agreed retention exception.
• Final reports and essential engagement records: Final reports, authorization records and relevant engagement activity records are retained for up to 12 months after final report delivery, unless the applicable agreement or law requires another period.
• Earlier deletion: A client may request earlier deletion in writing. We assess the request against contractual requirements, legitimate operational needs and applicable legal obligations.
• Legal holds: Information relevant to a reasonably anticipated dispute, claim or legal obligation may be preserved for as long as required.
• Backups and secondary copies: Deletion from active storage may not immediately remove every backup or archived copy. Those copies remain subject to access restrictions and the applicable backup lifecycle, with deletion applied again where data is restored.

Operational ICT logs are handled in accordance with applicable legal requirements. Where CERT-In Directions apply, the relevant log-retention and India-location requirements must be met.

Any engagement-specific retention exception should be documented in writing. Trixent should publish fixed backup-expiry periods only after confirming that its backup and storage systems consistently meet them.

11. Incident and Breach Notification

If we become aware of an actual or reasonably suspected incident involving unauthorized access to, loss of or disclosure of client engagement data, we assess and take appropriate steps to contain the incident and investigate its impact.

We notify the affected client without undue delay and in accordance with the applicable contract or DPA. The notification process should identify, to the extent known:

• The nature of the incident and the information potentially affected.
• The known or suspected impact.
• Containment measures taken or planned.
• Immediate protective actions the client should consider.
• A contact for coordination and subsequent updates.

Where all details are not yet known, an initial notification may be followed by further information as the investigation progresses.

Statutory reporting obligations are separate from client notification obligations. Where applicable law requires reporting to an authority such as CERT-In, the relevant reporting deadline and process apply independently of any contractual deadline.

12. Confidentiality and Disclosure

Client information and engagement findings are treated as confidential and are disclosed only for authorized service delivery or another permitted purpose under the applicable agreement or law.

Ownership and permitted use of client-provided data, engagement reports, deliverables, pre-existing tools, methodologies and other intellectual property are governed by the applicable signed agreements.

We do not publish client names, findings, reports or identifiable engagement details without the necessary permission or other lawful basis.

Any permitted use of anonymized or aggregated information must be consistent with the applicable agreement and must not disclose confidential client information or reasonably identify a client.

Where disclosure is required by law or a valid legal order, we comply with the applicable requirement. Where legally permitted, we notify the affected client in advance.

13. Safe Testing and Testing Infrastructure

Testing activities are limited to the scope, timing and techniques agreed in the RoE.

Denial-of-service and other disruptive tests are not performed without explicit written authorization and appropriate safeguards. For invasive testing on production systems, the parties should agree on recovery arrangements, emergency contacts and applicable risk controls before testing begins.

Testing systems and tools are managed to reduce the risk of exposing one client's information to another engagement. Temporary files, test accounts, uploaded files and other changes introduced during testing are removed when no longer required or at engagement completion, as appropriate.

Any material that cannot be removed safely is documented and reported to the client.

If we encounter evidence of a potentially active compromise in the client's environment, we pause the affected testing activity, notify the client's designated emergency contact and preserve only the evidence reasonably needed to explain the concern. Remediation or response actions outside the agreed scope require client authorization.

14. People and Confidentiality

Individuals working on an engagement must be informed of their confidentiality responsibilities and must be authorized to access the relevant client information.

Engagement personnel are expected to use protected devices, maintain appropriate account security, prevent unauthorized viewing or copying of client information and avoid storing engagement data in shared or public environments.

Access is removed when it is no longer required, including when personnel leave the engagement or change roles.

Any additional requirements relating to managed devices, personnel screening, approved contractors or backup coverage should be documented in internal procedures and applied consistently before they are represented as established controls in this policy.

15. AI Tools and Online Services

Client information, credentials, vulnerability findings and evidence must not be submitted to public AI tools or unapproved online services for processing unless the client has expressly authorized the use and the service has been assessed for the intended confidential material.

Where an AI or automated analysis service is approved, its use must comply with the engagement authorization, data minimization requirements, service terms and confidentiality obligations.

AI-generated actions against client systems require explicit authorization in the RoE and appropriate supervision. A tool's ability to act autonomously does not expand the authorized scope, and responsibility for permitted activity remains with the assigned human operator.

Client files and confidential samples must not be uploaded to public scanners, decoders, password-analysis services, paste sites or similar services unless the engagement expressly authorizes the use and the information-handling risks have been assessed.

16. Our Own Systems

Systems used to access or store engagement information should be maintained with appropriate security updates, access controls, endpoint protections and monitoring.

Access rights are reviewed as personnel join, change responsibilities or leave. Relevant engagement activity records may include testing source addresses, time windows and actions needed to help the client correlate authorized testing with its own monitoring.

The specific records shared with a client are determined by the engagement documentation and the purpose of the request, while protecting other clients' confidential information.

17. Client Assurance and Audits

Clients may request reasonable information about the safeguards applicable to their engagement, subject to confidentiality requirements and the information that can be appropriately disclosed.

Formal audit rights, notice periods, audit scope, costs, frequency, confidentiality and protections for other clients are governed by the applicable signed contract or DPA.

This public policy does not independently grant an unrestricted right to inspect Trixent Security's systems, personnel records, other client environments or confidential third-party information.

18. Reporting a Security Concern

To report a suspected security issue affecting the Trixent Security website or our handling of information, email:

contact@trixentsecurity.com

Use the subject line Security Report. Include a concise description of the issue, the affected URL or component, safe reproduction details and relevant redacted evidence.

Do not include passwords, access tokens, private keys, unnecessary personal information or data belonging to other parties. Do not access additional data, disrupt services or expand testing beyond your existing authorization to demonstrate a finding.

We review reports and may request clarification or additional information. Acknowledgement and remediation depend on the nature of the report, the evidence available and the investigation required.

This reporting channel does not authorize security testing of Trixent Security's systems or any client or third-party environment, and it does not provide blanket legal immunity.

If Trixent Security publishes a vulnerability-disclosure programme, a security.txt file or an encryption key, the relevant scope and reporting instructions should be made available through verified, maintained public resources.

19. Changes to This Policy

We may revise this policy as our practices, services or legal obligations change.

Each published revision should carry its actual publication date and version number. Changes affecting an active engagement are handled in accordance with the applicable signed agreement and any notice obligations contained in it.

This policy does not independently amend an existing contract. Where a contractual amendment is required, it must be handled through the agreed process.