Effective Date: August 9, 2026
Last Updated: August 9, 2026

​

Global Standard Certified Alliance ("GSCA"), operated by Techevent Limited and its affiliated entities ("GSCA", "we", "us", or "our"), operates a global digital trust infrastructure supporting identity, verification, digital credentials, eAssets, provenance, certification, authentication, and related trust services.

​

Security and system integrity are fundamental to the GSCA Trust Infrastructure.

​

This GSCA Security & Responsible Disclosure Policy ("Policy") describes our general approach to security and provides a framework for reporting suspected security vulnerabilities or incidents affecting GSCA Services.

​

This Policy should be read together with the GSCA Terms of Service, Privacy Policy, Cookie Policy, Acceptable Use & Trust Integrity Policy, Payment, Billing & Refund Policy, and Intellectual Property & Trademark Policy.

 

1. Our Security Principle

GSCA is designed around the principle that digital trust requires the protection of:

1. Identity;

2. Credentials;

3. Digital assets;

4. Verification records;

5. Provenance information;

6. Authentication mechanisms;

7. Account access;

8. System integrity;

9. Availability of GSCA Services.

GSCA continuously seeks to maintain appropriate technical and organizational safeguards designed to protect the confidentiality, integrity, and availability of information and services within the GSCA ecosystem.

 

2. Scope of Security

Depending on the applicable GSCA Service, security measures may address:

1. User accounts;

2. ONE ID and identity-related services;

3. Digital certificates;

4. eAssets;

5. eOrigin records;

6. eStamp services;

7. NFC and QR-based verification;

8. APIs and integrations;

9. Cloud infrastructure;

10. Databases and system services;

11. Authentication mechanisms;

12. Access controls;

13. Administrative systems;

14. Network and application security;

15. Security monitoring and logging;

16. Backup and recovery processes.

The specific technical implementation may vary between GSCA Services and may be updated as the GSCA Trust Infrastructure evolves.

 

3. Identity and Access Security

GSCA may implement appropriate access controls designed to ensure that users and organizations can only access functions and information for which they are authorized.

Depending on the service, security controls may include:

1. Authentication;

2. Multi-factor authentication;

3. Role-based access controls;

4. Account verification;

5. Authorization controls;

6. Credential management;

7. Session controls;

8. Security monitoring;

9. Other appropriate technical safeguards.

Users are responsible for maintaining the confidentiality of their account credentials and for taking reasonable measures to protect their accounts.

 

4. Data Protection and Encryption

GSCA uses appropriate security measures to protect information processed through its services.

Depending on the applicable system and service, these measures may include:

1. Encryption in transit;

2. Encryption or other protective measures for stored information;

3. Cryptographic verification;

4. Secure authentication;

5. Access controls;

6. Integrity protection;

7. Security monitoring.

GSCA does not publicly disclose sensitive technical details that could materially weaken the security of its systems.

 

5. Digital Trust and Integrity Protection

Because GSCA operates a Trust Infrastructure, maintaining the integrity of digital records is a core security objective.

GSCA may use technical and organizational controls designed to help protect against:

1. Unauthorized modification;

2. Credential manipulation;

3. Identity fraud;

4. Unauthorized issuance;

5. Counterfeit digital records;

6. Unauthorized asset transfers;

7. Tampering with verification information;

8. Unauthorized access;

9. System abuse.

Where appropriate, GSCA may monitor relevant system activity to identify suspicious behavior or potential security incidents.

 

6. NFC, QR and Physical Trust Identifiers

Where GSCA Services use NFC tags, QR codes, digital identifiers, or other physical-to-digital trust mechanisms, GSCA may implement controls designed to support:

1. Identifier verification;

2. Authentication;

3. Record integrity;

4. Unauthorized-use detection;

5. Asset association;

6. Verification status.

Users must not attempt to clone, manipulate, redirect, replace, or otherwise misuse GSCA identifiers for fraudulent or unauthorized purposes.

Such activities may constitute a violation of the GSCA Acceptable Use & Trust Integrity Policy.

 

7. API and Integration Security

Where GSCA provides APIs, SDKs, or other integration services, appropriate security controls may include:

1. Authentication;

2. Authorization;

3. API credentials;

4. Access restrictions;

5. Rate limitations;

6. Monitoring;

7. Logging;

8. Other technical safeguards.

Developers and integration partners are responsible for protecting their API credentials and using GSCA APIs only within the scope of their authorization.

Compromised or suspected compromised credentials should be reported to GSCA as soon as reasonably possible.

 

8. Security Monitoring

GSCA may monitor system activity and security events to:

1. Detect unauthorized access;

2. Identify suspicious activity;

3. Investigate security incidents;

4. Protect system availability;

5. Protect user accounts;

6. Protect the integrity of GSCA Services;

7. Support incident response;

8. Meet applicable legal or regulatory requirements.

Security records may be retained in accordance with applicable laws, contractual requirements, operational needs, and the GSCA Privacy Policy.

 

9. Security Incidents

A security incident may include, without limitation:

1. Unauthorized access;

2. Account compromise;

3. Credential compromise;

4. Unauthorized disclosure of protected information;

5. Malware affecting GSCA systems;

6. Significant service disruption;

7. Unauthorized modification of protected records;

8. Suspected compromise of GSCA infrastructure;

9. Other events that may materially affect the security or integrity of GSCA Services.

Where GSCA identifies a security incident, we may take appropriate measures to:

1. Investigate the incident;

2. Contain the affected systems;

3. Protect users and services;

4. Restore affected services;

5. Preserve relevant security information;

6. Assess potential impact;

7. Notify affected parties where required by applicable law or contractual obligations;

8. Implement corrective or preventive measures.

 

10. Responsible Disclosure

GSCA encourages security researchers, developers, customers, partners, and other responsible individuals to report suspected security vulnerabilities.

Responsible disclosure helps GSCA identify and address security weaknesses before they can be exploited to harm users or compromise the Trust Infrastructure.

If you believe you have identified a security vulnerability affecting a GSCA Service, please report it to us promptly.

 

11. What to Include in a Security Report

Where possible, a security report should include sufficient information for GSCA to understand and reproduce the issue.

Useful information may include:

1. Description of the vulnerability;

2. Affected GSCA Service;

3. Affected URL, API, application, or function;

4. Steps required to reproduce the issue;

5. Relevant screenshots or technical evidence;

6. Potential security impact;

7. Suggested mitigation, if available;

8. Your contact information.

Please do not include unnecessary personal information or confidential information belonging to other users.

 

12. Responsible Security Testing

Security researchers and other parties reporting vulnerabilities should:

1. Test only systems and services that are within the intended scope of their authorized activity;

2. Avoid accessing or modifying data belonging to other users;

3. Avoid disrupting GSCA Services;

4. Avoid destructive testing;

5. Avoid denial-of-service testing;

6. Avoid social engineering of GSCA personnel;

7. Avoid physical attacks against GSCA facilities;

8. Avoid installing persistent access mechanisms;

9. Avoid copying or retaining unnecessary personal information;

10. Stop testing when sufficient evidence has been obtained to demonstrate the vulnerability.

Where possible, researchers should use test accounts or their own accounts.

 

13. Prohibited Security Testing

Unless expressly authorized in writing by GSCA, security testing must not include:

1. Denial-of-service or distributed denial-of-service attacks;

2. Flooding or stress testing intended to disrupt services;

3. Destructive actions;

4. Data deletion or corruption;

5. Unauthorized access to another person's account;

6. Unauthorized access to personal or confidential information;

7. Social engineering of employees, customers, or partners;

8. Physical attacks;

9. Malware deployment;

10. Persistence mechanisms;

11. Credential theft;

12. Exploitation intended to cause material harm.

Unauthorized testing may be treated as a violation of the GSCA Acceptable Use & Trust Integrity Policy and may result in appropriate action.

 

14. Protection of User Data During Security Research

Security researchers must make reasonable efforts to minimize access to personal, confidential, or proprietary information.

If personal or confidential information is unintentionally accessed during authorized security research, the researcher should:

1. Stop accessing the information;

2. Avoid copying or distributing it;

3. Delete unnecessary copies;

4. Notify GSCA promptly;

5. Provide only the minimum information necessary to demonstrate the vulnerability.

 

15. Good-Faith Security Research

GSCA encourages good-faith security research conducted responsibly and within the scope of this Policy.

Where a security researcher:

1. Acts in good faith;

2. Avoids unnecessary harm;

3. Does not intentionally access or disclose unrelated confidential information;

4. Reports the vulnerability promptly;

5. Gives GSCA a reasonable opportunity to investigate and address the issue;

GSCA will consider the circumstances when determining an appropriate response.

This Policy does not create a contractual guarantee of immunity from legal action, and it does not authorize activity that is otherwise prohibited by law.

 

16. Coordinated Disclosure

GSCA may work with security researchers to coordinate the disclosure of significant vulnerabilities.

Depending on the circumstances, GSCA may:

1. Request reasonable time to investigate;

2. Develop and deploy a mitigation;

3. Request that technical details remain confidential temporarily;

4. Coordinate disclosure timing;

5. Acknowledge the contribution of the researcher where appropriate.

GSCA may determine the appropriate disclosure approach based on security risk, user impact, applicable law, and operational considerations.

 

17. Third-Party Services

GSCA may rely on third-party infrastructure, cloud providers, payment providers, authentication services, communication services, or other technology providers.

Security incidents involving third-party services may be subject to the relevant provider's security procedures and contractual arrangements.

GSCA may work with relevant providers where necessary to investigate and mitigate security incidents affecting GSCA Services.

 

18. Security Responsibilities of Users

Security is a shared responsibility.

Users should:

1. Protect account credentials;

2. Use strong and unique passwords;

3. Enable additional security controls where available;

4. Keep devices and software reasonably secure;

5. Avoid sharing authentication credentials;

6. Monitor account activity;

7. Report suspected account compromise;

8. Keep contact information reasonably current;

9. Use GSCA Services only through authorized channels.

Organizations should also implement appropriate internal access controls for employees, administrators, agents, and other authorized users.

 

19. Reporting Account or Credential Compromise

If you believe that your GSCA account, ONE ID, API credentials, authentication credentials, or other security credentials have been compromised, contact GSCA as soon as reasonably possible.

GSCA may take measures including:

1. Credential suspension;

2. Account restriction;

3. Access revocation;

4. Identity verification;

5. Security investigation;

6. Credential replacement;

7. Other protective measures.

 

20. Security Updates and Improvements

GSCA may periodically update its systems, security controls, software, infrastructure, and procedures.

These changes may include:

1. Security patches;

2. Infrastructure upgrades;

3. Authentication improvements;

4. Monitoring improvements;

5. Access-control changes;

6. Cryptographic improvements;

7. Backup and recovery improvements;

8. Vulnerability remediation.

GSCA may make security-related changes without prior notice where reasonably necessary to protect the Trust Infrastructure or its users.

 

21. Service Availability and Security

GSCA takes reasonable measures to maintain the availability and resilience of its services.

However, no digital infrastructure can guarantee continuous availability or complete protection against every:

1. Cyberattack;

2. Security vulnerability;

3. Infrastructure failure;

4. Internet disruption;

5. Third-party failure;

6. Natural disaster;

7. Other unforeseen event.

Users should maintain appropriate business continuity and operational procedures where GSCA Services are critical to their activities.

 

22. No Guarantee of Absolute Security

GSCA implements reasonable technical and organizational security measures appropriate to the nature of its services.

However:

No system, network, application, database, authentication mechanism, or digital trust infrastructure can be guaranteed to be completely secure.

Accordingly, GSCA does not guarantee that its Services will be completely free from vulnerabilities, unauthorized access, security incidents, or other security risks.

 

23. Relationship with the GSCA Trust Integrity Policy

Security incidents and technical vulnerabilities are distinct from intentional misuse of GSCA Services.

Where conduct involves deliberate abuse, fraud, unauthorized access, credential manipulation, counterfeit credentials, or attempts to undermine GSCA Trust mechanisms, the GSCA Acceptable Use & Trust Integrity Policy may also apply.

GSCA may take action under both policies where appropriate.

 

24. Security Contact and Vulnerability Reporting

For security concerns, suspected vulnerabilities, compromised credentials, or responsible disclosure reports, please contact:

Global Standard Certified Alliance (GSCA)
Operated by Techevent Limited

Security Contact:
Email: neksun@ecert.app

When reporting a vulnerability, please use the subject:

SECURITY REPORT — [Brief Description]

Please do not publicly disclose sensitive vulnerability details before GSCA has had a reasonable opportunity to investigate and respond.

 

25. Policy Updates

GSCA may update this Policy from time to time to reflect:

1. Changes in technology;

2. New GSCA Services;

3. Security improvements;

4. New security risks;

5. Changes in applicable laws;

6. Changes in the GSCA Trust Infrastructure;

7. Improvements to incident response procedures.

The latest version will be published on the applicable GSCA website.

Unless otherwise required by law, continued use of GSCA Services after the effective date of an updated Policy constitutes acceptance of the revised Policy.

 

26. Contact Us

For general questions concerning this Policy, security governance, or GSCA security practices:

Global Standard Certified Alliance (GSCA)
Operated by Techevent Limited

Email: cs@ecert.app
Website: www.ecert.app / www.gsca.cc