CLIDE Customer-Requested VAPT Policy

Document Type: Information Security Policy
Policy Owner: CLIDE Management Consultancy Pvt. Ltd.
Applicable To: CLIDE Analyser Web Application, Mobile Applications, APIs and related environments
Version: 1.2
Effective Date: 21 Jan 2023
Review Frequency: Annual or upon significant change in technology/security requirements

1. Purpose

CLIDE Management Consultancy Pvt. Ltd. (“CLIDE”) is committed to maintaining the security, confidentiality, integrity and availability of the CLIDE Analyser platform.

This policy establishes the framework under which customers, customer-appointed auditors, independent security firms or other authorised third parties may conduct Vulnerability Assessment and Penetration Testing (“VAPT”) of CLIDE Analyser.

The purpose of this policy is to:

  • support reasonable customer security-assurance requirements;
  • facilitate controlled and authorised security testing;
  • protect CLIDE's infrastructure and intellectual property;
  • protect the data of CLIDE and its customers;
  • prevent unintended impact to other customers or production services;
  • establish clear responsibilities between CLIDE and the testing party;
  • define requirements for testing, reporting, remediation and re-testing.

Security testing shall be conducted only within an agreed scope and under documented rules of engagement. NIST similarly recommends defining the purpose, scope, assumptions, risks, personnel and schedule before security testing begins.

2. Scope

This policy applies when a customer requests or requires security testing of any of the following:

  • CLIDE Analyser Web Application;
  • CLIDE Analyser Mobile Application;
  • CLIDE Analyser APIs;
  • application authentication and authorisation mechanisms;
  • application business logic;
  • application configuration;
  • designated Stage/UAT environments;
  • designated infrastructure components, where expressly included;
  • integrations specifically identified in the approved VAPT scope.

The policy applies whether the testing is conducted by:

  • the customer;
  • a customer-appointed VAPT company;
  • an independent security assessor;
  • an auditor;
  • another authorised third party.

3. Existing CLIDE Security Assessments

CLIDE may periodically conduct independent security assessments and VAPT assessments of its products and infrastructure.

Where appropriate, CLIDE may provide existing VAPT reports, certificates, executive summaries or other security-assurance evidence to customers under applicable confidentiality arrangements.

A customer-requested VAPT is considered an additional customer-specific assurance activity and does not necessarily indicate that CLIDE has not previously conducted security assessments.

Existing VAPT reports may be considered by the customer when determining the appropriate scope of any additional assessment.

4. Mandatory Pre-Assessment Requirements

No customer-requested VAPT shall commence until the following have been completed:

4.1 Written authorization

The customer must provide written authorization identifying:

  • the customer;
  • the testing organisation;
  • authorised testers;
  • testing dates;
  • systems/assets covered;
  • source IP addresses where applicable;
  • testing methodology;
  • applicable restrictions.

4.2 NDA

Where the testing party is an external organisation, an appropriate Non-Disclosure Agreement (NDA) must be executed before CLIDE provides:

  • credentials;
  • architecture information;
  • technical documentation;
  • source-code information, if applicable;
  • security configuration information;
  • confidential test information.

4.3 Rules of Engagement

A written Rules of Engagement (ROE) or equivalent scope document shall be agreed before testing.

The ROE shall define the permitted activities and constraints. NIST defines ROE as the detailed guidelines and constraints established before testing that give the test team authority to conduct defined activities without obtaining additional permission. NIST Computer Security Resource Center

5. Preferred Testing Environment

5.1 Stage/UAT Environment

As a default, customer-requested VAPT shall be conducted against a designated Stage/UAT environment.

The Stage/UAT environment should:

  • be isolated from production where technically feasible;
  • contain test accounts;
  • use non-production/test data;
  • avoid unnecessary customer personal data;
  • avoid production attachments and documents;
  • avoid live customer transactions.

5.2 Production Testing

Testing against production systems is not permitted by default.

Production testing may only occur where: India Govt have asked

  1. CLIDE has reviewed and approved the request;
  2. the scope and testing window are documented;
  3. appropriate safeguards are established;
  4. the customer (India Govt) accepts the operational risks associated with production testing.

CLIDE reserves the right to refuse production testing where it considers the activity likely to create unacceptable operational, security, availability or customer-impact risk.

6. VAPT Methodology

The exact methodology shall be agreed before commencement.

Depending on the requirement, the assessment may include:

Black Box Testing

Testing with limited or no internal application information.

Grey Box Testing

Testing using controlled test accounts and selected technical information.

White Box Testing

Testing with extensive technical information or source-code access, where specifically agreed.

Automated Testing

Automated vulnerability scanning may be used as part of the assessment.

Manual Testing

Manual penetration testing may be performed for application-specific security weaknesses, business logic, authentication, authorisation and other areas where manual assessment provides additional assurance.

For CLIDE Analyser, Grey Box + Manual Testing is generally the preferred approach for meaningful application-level assessment, where appropriate.

OWASP's Web Security Testing Guide provides a broad framework covering areas including authentication, authorization, session management, input validation, cryptography, business logic and API testing. OWASP Foundation

7. Application Testing Scope

The approved scope may include:

  • information gathering;
  • configuration and deployment testing;
  • authentication;
  • password management;
  • multi-factor authentication;
  • authorization;
  • privilege escalation;
  • session management;
  • input validation;
  • injection vulnerabilities;
  • cross-site scripting;
  • insecure direct object references;
  • file upload/download controls;
  • API security;
  • cryptographic controls;
  • business logic;
  • access-control testing;
  • error handling;
  • security headers;
  • mobile application security;
  • applicable OWASP testing areas.

The exact scope shall depend on the application architecture and the customer's agreed assessment objectives.

OWASP describes its WSTG as a flexible testing framework rather than a rigid checklist, allowing the testing approach to be adapted to the organisation and threat model. OWASP Web Security Testing Guide

8. Activities Prohibited Without Explicit Approval

The following activities are prohibited unless specifically approved in writing by CLIDE:

  • Denial-of-Service (DoS) testing;
  • Distributed Denial-of-Service (DDoS) testing;
  • destructive testing;
  • intentional deletion of production data;
  • database destruction;
  • ransomware simulation;
  • uncontrolled brute-force attacks;
  • mass account lockout testing;
  • social engineering;
  • phishing;
  • physical security testing;
  • attacks against third-party infrastructure;
  • attacks against AWS infrastructure outside the agreed scope;
  • testing of other CLIDE customers;
  • testing of production systems without written approval;
  • intentional disruption of availability;
  • exploitation designed to cause permanent system modification.

9. Protection of Customer and Third-Party Data

The testing organisation shall use only the minimum information necessary to conduct the assessment.

Where feasible:

  • test data shall be used;
  • personal data shall be avoided;
  • production data shall not be downloaded;
  • customer data shall not be copied to tester-controlled systems;
  • screenshots containing personal/confidential data should be minimised;
  • extracted data must be securely deleted after assessment.

The tester shall not attempt to access data belonging to other customers.

If unintended access to customer or third-party data occurs, the tester must:

  1. immediately stop the relevant activity;
  2. avoid further access;
  3. notify CLIDE;
  4. preserve sufficient evidence for investigation;
  5. securely delete unauthorised copies when instructed.

10. Testing Credentials

CLIDE may provide controlled test credentials.

Credentials shall:

  • be created specifically for the assessment;
  • have only the privileges necessary for testing;
  • be time-limited where technically feasible;
  • not be shared with unauthorised persons;
  • not be used outside the agreed scope.

Where possible, separate accounts should be created for different roles, such as:

  • Administrator;
  • Manager;
  • Standard User;
  • Restricted User.

11. Testing Window

Testing shall be performed only during the agreed testing period.

The customer/testing organisation shall provide:

  • proposed start date;
  • proposed end date;
  • expected testing hours;
  • tester contact details;
  • emergency contact details.

CLIDE may temporarily suspend testing if:

  • system availability is affected;
  • unexpected production impact occurs;
  • another security incident occurs;
  • testing exceeds the approved scope;
  • suspicious activity is detected;
  • the testing creates unacceptable operational risk.

12. Vulnerability Reporting

The testing organisation shall provide CLIDE with a complete report containing, where applicable:

  • vulnerability title;
  • vulnerability description;
  • severity;
  • CVSS score/version, where used;
  • affected URL/API/component;
  • affected application/module;
  • reproduction steps;
  • technical evidence;
  • screenshots or logs;
  • business impact;
  • recommended remediation;
  • vulnerability status.

All findings must be shared with CLIDE for review and validation before being considered final.

13. Finding Validation

CLIDE shall have the opportunity to review each reported finding.

CLIDE may classify a finding as:

  • Valid;
  • False Positive;
  • Not Applicable;
  • Duplicate;
  • Accepted Risk;
  • Requires Further Investigation;
  • Remediated.

Where CLIDE disputes a finding, CLIDE may provide technical evidence or explanation to the testing organisation.

The final report should distinguish between confirmed vulnerabilities and findings that remain disputed or unverified.

14. Severity Classification

Where applicable, vulnerabilities should be classified using a recognised methodology such as CVSS.

As a general prioritisation:

Severity CLIDE Response Priority
Critical Immediate investigation and prioritised remediation
High High-priority remediation
Medium Planned remediation
Low Risk-based remediation
Informational Review and improvement where appropriate


Severity does not automatically determine whether a vulnerability is exploitable in the CLIDE environment. CLIDE shall consider:

  • exploitability;
  • affected component;
  • actual exposure;
  • authentication requirements;
  • customer configuration;
  • compensating controls;
  • business impact;
  • likelihood;
  • applicability.

15. Remediation

CLIDE shall review identified vulnerabilities and determine appropriate action.

Depending on the risk, CLIDE may:

  • remediate the vulnerability;
  • implement a compensating control;
  • modify configuration;
  • modify application functionality;
  • restrict access;
  • provide additional monitoring;
  • accept the residual risk;
  • determine that the finding is not applicable.

Critical and High-risk findings shall generally receive priority.

No customer-requested VAPT policy shall be interpreted as a commitment that every reported observation will necessarily result in a product change.

16. Re-Testing

The standard customer-requested VAPT process shall include:

Round 1

Initial VAPT assessment.

Round 2

One consolidated remediation re-test covering findings from Round 1.

The re-test shall normally be limited to:

  • previously identified vulnerabilities;
  • affected components;
  • implemented remediation;
  • reasonable verification of closure.

Additional VAPT rounds, expanded scope, new modules, new releases or newly introduced functionality shall be treated as separate assessments and require mutual agreement.

17. No Unlimited Testing Commitment

Customer participation in the VAPT process does not constitute an agreement to provide unlimited penetration testing or unlimited remediation cycles.

Any of the following may constitute a new assessment:

  • additional application;
  • additional mobile platform;
  • additional API;
  • production testing;
  • infrastructure testing;
  • source-code review;
  • new major application release;
  • material architectural change;
  • additional testing round;
  • testing outside the originally agreed scope.

18. Mobile Application Testing

Where CLIDE Analyser mobile applications are included, the scope shall identify:

  • Android;
  • iOS;
  • supported application versions;
  • application package/build;
  • API endpoints;
  • authentication mechanisms;
  • test accounts.

Testing may include:

  • secure storage;
  • authentication;
  • authorization;
  • session handling;
  • API security;
  • certificate/TLS configuration;
  • local data storage;
  • application permissions;
  • reverse engineering resistance where applicable;
  • insecure data exposure;
  • application configuration.

19. API Testing

Where APIs are included, testing may cover:

  • authentication;
  • authorization;
  • token management;
  • input validation;
  • rate limiting;
  • access control;
  • object-level authorization;
  • injection;
  • information disclosure;
  • API configuration;
  • error handling.

Testing shall be limited to APIs specifically included in the approved scope.

20. Infrastructure and Cloud Testing

Infrastructure or cloud penetration testing shall not automatically be included merely because the application is hosted on cloud infrastructure.

If AWS/cloud infrastructure testing is required, the scope shall separately identify:

  • accounts;
  • regions;
  • services;
  • IP addresses;
  • cloud components;
  • security groups;
  • APIs;
  • network components.

Testing of cloud-provider infrastructure itself remains outside CLIDE's control and shall be subject to applicable cloud-provider policies.

21. Source Code

Source-code review is not included in a standard VAPT unless specifically agreed.

Where source code is provided:

  • NDA/confidentiality obligations apply;
  • access shall be limited to authorised personnel;
  • code shall not be copied or retained beyond the agreed period;
  • source code shall not be shared with unauthorised third parties;
  • intellectual property remains with CLIDE.

22. Intellectual Property

All CLIDE software, architecture, source code, documentation, configurations, designs, databases and proprietary information remain the intellectual property or confidential information of CLIDE or its respective licensors.

VAPT testing does not grant the tester or customer any ownership rights over CLIDE intellectual property.

23. Confidentiality

The testing organisation shall maintain strict confidentiality regarding:

  • vulnerabilities;
  • security weaknesses;
  • credentials;
  • architecture;
  • source code;
  • application configuration;
  • customer data;
  • CLIDE security controls;
  • VAPT reports.

VAPT findings shall not be published, disclosed, demonstrated or shared with any third party without CLIDE's written approval, except where disclosure is legally required.

24. Handling of VAPT Reports

VAPT reports may contain sensitive security information.

Accordingly:

  • reports should be transmitted securely;
  • access should be limited to authorised personnel;
  • reports should not be publicly disclosed;
  • detailed vulnerability information should not be posted on public platforms;
  • copies should be securely deleted when no longer required.

CLIDE may provide appropriate portions of the report to relevant customers, auditors, regulators or certification bodies subject to confidentiality requirements.

25. Third-Party Testing Organisation

Where the customer appoints a third-party VAPT organisation, the customer shall ensure that the testing organisation:

  • has appropriate technical competence, - only CERT-In empaneled TPO;
  • has appropriate confidentiality obligations;
  • follows professional security-testing practices;
  • complies with the agreed scope;
  • handles information securely;
  • does not subcontract testing without appropriate authorization.

CLIDE may request details of the testing organisation and proposed methodology before approving access.

26. Incident During Testing

If testing causes or appears likely to cause:

  • service degradation;
  • security incident;
  • data exposure;
  • unexpected system behaviour;
  • availability issues;
  • account lockout;
  • database impact;

the testing organisation must immediately stop the affected test activity and notify CLIDE.

CLIDE may terminate or suspend the testing activity where necessary to protect the platform or customers.

27. Limitation of Testing Responsibility

CLIDE shall not be responsible for consequences arising from:

  • testing conducted outside the approved scope;
  • unauthorised testing;
  • testing performed outside the approved window;
  • tester error;
  • misuse of credentials;
  • testing against systems not authorised by CLIDE;
  • activities conducted by the customer or third party without CLIDE approval.

The customer/tester remains responsible for activities performed using credentials or access provided to them.

28. No Guarantee of Vulnerability-Free Software

VAPT is a point-in-time security assessment.

Completion of a VAPT assessment or issuance of a VAPT certificate does not constitute a guarantee that:

  • the application is completely vulnerability-free;
  • no future vulnerabilities will occur;
  • all vulnerabilities have been identified;
  • the application will remain secure against future threats.

Security posture may change due to:

  • software releases;
  • configuration changes;
  • third-party dependencies;
  • newly discovered vulnerabilities;
  • infrastructure changes;
  • changes in threat landscape.

29. Changes Following VAPT

Where material changes are made to CLIDE Analyser after completion of a VAPT, CLIDE may conduct additional security testing based on its internal risk assessment.

A customer may request additional testing following a material change, subject to agreement on scope and timing.

30. Evidence of Security Assurance

Depending on the customer's requirements, CLIDE may provide appropriate evidence such as:

  • VAPT reports;
  • VAPT certificates;
  • remediation summaries;
  • security assessment summaries;
  • relevant certifications;
  • security policies;
  • architecture documentation;
  • security-control evidence.

The specific evidence provided may be subject to confidentiality, security and intellectual-property restrictions.

31. Customer Responsibilities

The customer shall:

  • define its security requirements clearly;
  • provide written authorization;
  • identify the testing organisation;
  • ensure the testing organisation follows this policy;
  • provide appropriate test accounts where required;
  • avoid using production personal data where possible;
  • maintain confidentiality of CLIDE security information;
  • ensure the tester does not exceed the agreed scope.

32. CLIDE Responsibilities

CLIDE shall:

  • provide the agreed testing environment;
  • provide required test access where appropriate;
  • define the scope and testing restrictions;
  • support reasonable technical coordination;
  • review identified findings;
  • investigate applicable vulnerabilities;
  • implement remediation based on risk and feasibility;
  • coordinate one agreed remediation re-test where applicable.

33. Standard VAPT Lifecycle

The standard lifecycle is:

Customer Request
↓
NDA
↓
Written Authorization
↓
Scope Definition
↓
Rules of Engagement
↓
Stage/UAT Environment
↓
Test Credentials
↓
VAPT Round 1
↓
Vulnerability Report
↓
CLIDE Validation
↓
Remediation
↓
VAPT Re-Test
↓
Closure Report

34. Recommended Standard Engagement

Unless otherwise agreed, CLIDE's standard customer-requested VAPT engagement consists of:

One initial VAPT assessment + one consolidated remediation re-test.

Any additional testing will be evaluated based on:

  • scope;
  • risk;
  • application changes;
  • customer requirements;
  • testing effort;
  • technical feasibility.

35. Policy Exceptions

Any exception to this policy must be approved by an authorised CLIDE representative.

Exceptions may include:

  • production testing;
  • infrastructure testing;
  • DoS testing;
  • source-code review;
  • additional testing rounds;
  • testing outside the agreed window;
  • access to production data.

Exceptions must be documented before the activity begins.

36. Policy Review

This policy shall be reviewed at least annually or when there is a significant:

  • change in CLIDE Analyser architecture;
  • change in hosting infrastructure;
  • change in security requirements;
  • change in regulatory requirements;
  • change in VAPT methodology;
  • security incident;
  • customer requirement.

Note - This policy describes CLIDE's standard approach to customer-requested security testing. Individual VAPT engagements may be subject to additional or different requirements agreed in writing between CLIDE and the relevant customer. The applicable statement of work, Rules of Engagement, authorization and contractual terms shall prevail in the event of any inconsistency with this policy.