RANAPAY INDIA PRIVATE LIMITED

This Policy establishes requirements for granting, managing, reviewing and revoking access to RanaPay systems, applications, data, APIs and technology resources, with specific controls for secure API connectivity and integration.

• Apply least-privilege access.
• Prevent unauthorised access.
• Secure employee, administrator and vendor access.
• Protect API credentials and interfaces.
• Monitor privileged and sensitive access.
• Ensure timely access revocation.
• Support secure partner integrations.

This Policy applies to employees, contractors, vendors, administrators, service accounts, applications, APIs, databases, cloud resources, endpoints and other systems used by RanaPay.

• Least privilege
• Need to know
• Role-based access
• Segregation of duties
• Unique user identification
• Periodic review
• Timely revocation
• Accountability and logging

Users shall have unique identifiers wherever practicable. Shared accounts shall be avoided and permitted only where technically necessary and appropriately controlled.

1. Create access only after approval.
2. Modify access when role changes.
3. Revoke access promptly when employment/engagement ends.
4. Review privileged and third-party access after changes.

Access requests shall identify the user, system, role, business justification, access level and approving authority. Sensitive and privileged access requires enhanced approval.

• Strong passwords where applicable
• Multi-factor authentication for sensitive/privileged access
• Secure credential storage
• No credential sharing
• Prompt credential reset after compromise

Administrative access shall be restricted to authorised personnel, separately controlled where practicable, logged and periodically reviewed.

Access to critical systems, sensitive data, APIs and privileged functions shall be reviewed periodically based on risk. Unnecessary access shall be removed.

Third-party access shall be limited to the approved scope and duration. Vendor credentials shall be unique where practicable and disabled when no longer required.

Service accounts shall have documented owners, defined purposes, restricted permissions and secure credentials. Unused accounts shall be disabled or removed.

• Use secure authentication and authorisation.
• Encrypt API traffic using appropriate secure transport.
• Validate all inputs.
• Apply rate limiting where appropriate.
• Restrict exposed endpoints.
• Maintain API logs.
• Protect API secrets.
• Monitor unusual API activity.

APIs shall use an approved authentication mechanism appropriate to the risk, such as securely managed tokens, keys, certificates or other approved mechanisms. Secrets shall never be hard-coded into publicly accessible code.

Authentication alone shall not grant unrestricted access. API endpoints shall enforce appropriate permissions, roles, scopes and object-level authorisation.

• Store secrets in approved secure mechanisms
• Restrict access to credentials
• Rotate keys according to risk
• Revoke compromised credentials
• Do not share credentials through insecure channels
• Maintain ownership records

API inputs shall be validated and sanitised. Responses shall expose only information necessary for the authorised purpose and shall avoid unnecessary sensitive data.

Appropriate rate limits, throttling, quotas or other controls shall be applied to reduce abuse, automated attacks and excessive requests where technically appropriate.

• Authentication failures
• Authorisation failures
• High-risk endpoints
• Credential changes
• Unusual traffic
• Administrative changes
• Material errors

Material API changes shall follow change-management, testing and security review procedures. Deprecated interfaces shall be retired in a controlled manner.

Critical APIs may be subjected to vulnerability assessment, penetration testing, code review or other security testing appropriate to their risk.

Partner APIs shall undergo appropriate due diligence and technical security review before production use. Credentials, endpoints, certificates and data flows shall be documented and controlled.

APIs shall transmit only the data required for the approved business function. Sensitive fields should be masked or excluded where not required.

Development, testing and production environments shall be appropriately separated. Production access shall be restricted and monitored.

Suspected credential compromise, unauthorised access or API abuse shall be immediately escalated under the Cyber Incident Response & Cyber Fraud Policy.

Access shall be revoked when no longer required, upon termination, material role change, suspected compromise or other authorised trigger.

• Access request/approval
• User-role mapping
• Privileged access records
• Access review evidence
• Credential/key inventory
• API integration records
• Security review/testing results
• Revocation records
• Relevant logs

Users with privileged, technical or sensitive-data access shall receive appropriate security awareness and role-specific training.

Access and API controls may be reviewed through audits, access certifications, security testing, log reviews and other assurance activities.

Exceptions shall be documented, risk-assessed, approved and periodically reviewed. Mandatory legal, contractual or security requirements shall not be bypassed.

This Policy shall be reviewed at least annually and whenever there is a material change in technology, APIs, partner integrations, access architecture or applicable requirements.