On this page

In Summary

Anchor is designed to provide secure infrastructure for live Events, livestreaming, ticketing, payments, donations, communications, analytics, and Organization collaboration.

Our security approach includes:

encrypted communications;
secure password hashing;
session and token controls;
multi-factor authentication support;
role-based access controls;
Organization and tenant separation;
audit logging;
security monitoring;
rate limiting;
webhook verification;
controlled administrative access;
backups and disaster-recovery measures;
third-party infrastructure providers; and
incident investigation and response procedures.

No system can guarantee absolute security. Anchor uses a risk-based approach and continues to review and improve its safeguards as the Platform evolves.

This Security Overview is intended to provide transparency about Anchor's security practices. It does not create a warranty, service-level commitment, certification, or guarantee beyond obligations expressly stated in a written agreement.

Scope
Security Governance
Shared Responsibility
Infrastructure
Cloud Providers
Network and Transport Security
Encryption
Password Security
Authentication
Multi-Factor Authentication
Sessions and Tokens
Access Control
Organization and Tenant Isolation
Administrative Access
Application Security
Secure Development Practices
Dependency and Vulnerability Management
API and Webhook Security
Livestream and Media Security
Payment Security
Data Protection
Logging and Monitoring
Fraud and Abuse Prevention
Backups and Recovery
Availability and Resilience
Incident Response
Security Notifications
Third-Party Risk
Employee and Contractor Security
Customer Security Responsibilities
Event Organizer Security Responsibilities
Security Testing and Vulnerability Reporting
Data Retention and Deletion
Artificial Intelligence Security
Physical Security
Compliance and Assurance
Limitations
Changes to this Security Overview
Contact
Related Documents

1. Scope

This Security Overview applies to the technical, administrative, and organizational safeguards used to protect Anchor and the Personal Information, Event data, Organization data, communications, media, transaction records, and other information processed through the Platform.

It covers security practices relating to:

user Accounts;
Organizations and teams;
Events;
ticketing and registration;
payments and donations;
livestreams and recordings;
chat and audience-engagement tools;
notifications;
analytics;
application programming interfaces;
webhooks;
authentication;
artificial intelligence features;
cloud infrastructure; and
internal administrative systems.

Specific enterprise arrangements may include additional security commitments under a separate written agreement.

2. Security Governance

Aurelo Technologies is responsible for establishing and maintaining Anchor's security program.

The security program is designed to:

identify security risks;
protect Platform systems and information;
detect suspicious activity;
respond to security incidents;
recover from operational disruption;
manage access;
reduce the likelihood of unauthorized disclosure;
maintain Platform integrity; and
improve security practices over time.

Security responsibilities may be shared across engineering, infrastructure, product, operations, legal, privacy, support, and management functions.

Anchor may maintain internal policies, procedures, technical standards, access rules, incident-response processes, and review mechanisms appropriate to its size, architecture, and risk profile.

3. Shared Responsibility

Security is a shared responsibility between Anchor, Organizations, Event Organizers, users, infrastructure providers, and other service providers.

Anchor is responsible for protecting the Platform and systems under its control.

Organizations and users are responsible for:

protecting passwords and devices;
enabling available security features;
assigning appropriate roles;
reviewing Organization access;
removing former staff and contractors;
securing connected integrations;
protecting API credentials;
verifying payment and payout information;
configuring Event access correctly;
responding to suspicious activity; and
reporting suspected compromise promptly.

A security control provided by Anchor may be ineffective if a user disables it, misconfigures it, shares credentials, or grants excessive permissions.

4. Infrastructure

Anchor uses cloud-based infrastructure to host, process, store, and deliver the Services.

Depending on workload, region, and feature, Anchor may use infrastructure provided by:

Amazon Web Services;
Google Cloud;
Oracle Cloud; and
DigitalOcean.

These services may support application hosting, databases, compute resources, storage, networking, content delivery, backups, monitoring, media processing, logging, disaster recovery, and related technical functions.

Anchor may change infrastructure providers or deployment regions as the Platform evolves.

5. Cloud Providers

Anchor selects cloud and infrastructure providers based on factors such as reliability, scalability, security capabilities, geographic availability, operational maturity, service compatibility, resilience, contractual terms, and data-protection requirements.

Cloud providers are responsible for the security of their underlying facilities, hardware, core infrastructure, and managed services according to their respective shared-responsibility models.

Anchor remains responsible for configuring and operating the services it uses.

6. Network and Transport Security

Anchor uses encrypted network communications where appropriate.

Controls may include:

HTTPS;
Transport Layer Security;
secure database connections;
restricted network access;
firewall or security-group rules;
protected administrative interfaces;
controlled service-to-service communication;
domain and certificate management;
traffic filtering;
rate limiting; and
network monitoring.

Unencrypted protocols should not be used for sensitive production data where a secure alternative is reasonably available.

7. Encryption

Anchor uses encryption to reduce the risk of unauthorized access to information in transit and, where appropriate, at rest.

Encryption practices may include:

HTTPS and TLS for browser and API communications;
encrypted database connections;
encrypted storage provided by cloud infrastructure;
encryption of backups;
encrypted secret storage;
protected authentication tokens;
restricted key access; and
managed encryption services supplied by cloud providers.

Encryption is one part of Anchor's security program and is supported by access controls, monitoring, authentication, and operational procedures.

Anchor does not represent that every field or record is separately encrypted at the application level.

8. Password Security

Anchor supports email-and-password authentication.

Passwords are not intended to be stored in readable form.

Anchor uses secure password hashing, including bcrypt, to transform passwords before storage.

Password-security practices may include:

minimum password requirements;
protection against common or weak passwords;
rate limiting;
failed-login monitoring;
password reset controls;
session revocation after password changes;
secure recovery links;
expiration of recovery tokens; and
re-authentication for sensitive actions.

Users should choose a strong and unique password that is not reused on another service.

Anchor personnel should never request a user's password by email, chat, or telephone.

9. Authentication

Anchor supports authentication methods that may include:

email and password;
Google Sign-In;
JSON Web Tokens;
multi-factor authentication;
verification links;
password recovery;
device and session validation; and
additional security checks for sensitive actions.

Authentication controls are intended to verify user identity and reduce unauthorized Account access.

Google Sign-In may be subject to Google's own security, availability, and Account-management processes.

10. Multi-Factor Authentication

Anchor supports multi-factor authentication where available.

Multi-factor authentication adds another verification step beyond a password.

It may be required or recommended for:

Organization owners;
administrators;
finance-related roles;
high-risk Accounts;
sensitive administrative actions;
payout or billing changes;
Account recovery;
Organization ownership transfers; and
users with elevated permissions.

Users should enable multi-factor authentication where offered.

Multi-factor authentication reduces, but does not eliminate, the risk of Account compromise.

11. Sessions and Tokens

Anchor may use cookies, access tokens, refresh tokens, JSON Web Tokens, or similar technologies to maintain authenticated sessions.

Session-security controls may include:

expiration periods;
token rotation;
revocation;
secure cookie attributes;
inactivity timeouts;
device checks;
re-authentication for sensitive operations;
session invalidation after password changes;
invalidation after Account suspension or deletion; and
monitoring of suspicious session activity.

Authentication tokens must not be shared, published, logged unnecessarily, or embedded in insecure client-side code.

12. Access Control

Anchor applies access controls intended to limit information and functionality according to role and need.

Controls may include:

role-based access control;
Organization membership;
Event-specific permissions;
administrator roles;
finance roles;
moderator roles;
least-privilege principles;
restricted internal tools;
approval requirements;
temporary access;
access reviews; and
revocation procedures.

Users should receive only the permissions required for their responsibilities.

Organizations are responsible for assigning and reviewing user roles within their own teams.

13. Organization and Tenant Isolation

Anchor is designed to separate Organizations and their data.

Tenant-isolation measures may include:

Organization-scoped access checks;
authorization rules;
resource ownership validation;
restricted database queries;
role-based filtering;
separate credentials or secrets where appropriate;
audit logging;
testing of authorization boundaries; and
administrative controls.

A user's access to one Organization does not automatically grant access to another Organization.

Organizations must not attempt to access data belonging to another tenant.

14. Administrative Access

Internal administrative access is limited to authorized personnel who require access for legitimate operational purposes.

Administrative access may be used for:

technical support;
incident response;
security investigation;
fraud review;
legal compliance;
system maintenance;
Account recovery;
data correction;
debugging; and
Platform integrity.

Controls may include:

named user Accounts;
elevated-role restrictions;
multi-factor authentication;
least privilege;
approval procedures;
access logging;
periodic review;
secure devices;
session restrictions; and
prompt revocation when access is no longer required.

Administrative access is not intended for personal curiosity or unrelated monitoring.

15. Application Security

Anchor applies security controls throughout the application architecture.

These may include protection against:

unauthorized access;
injection attacks;
cross-site scripting;
cross-site request forgery;
broken access control;
insecure direct-object references;
session fixation;
credential stuffing;
brute-force attacks;
malicious uploads;
request forgery;
insecure redirects;
abuse of APIs;
excessive requests; and
common web-application threats.

Security controls may include validation, encoding, authentication, authorization, rate limiting, file restrictions, token verification, and monitoring.

16. Secure Development Practices

Anchor's development process may include:

source-code review;
version control;
controlled deployment;
development and production separation;
environment-specific credentials;
automated testing;
manual testing;
change review;
rollback procedures;
secret management;
logging review;
dependency review;
security testing; and
post-deployment monitoring.

Changes affecting authentication, payments, privacy, authorization, infrastructure, or sensitive data may receive additional review.

Production credentials should not be stored in public repositories or shared through insecure channels.

17. Dependency and Vulnerability Management

Anchor relies on software libraries, frameworks, operating systems, cloud services, and other dependencies.

Anchor may use processes to:

identify outdated dependencies;
review security advisories;
assess vulnerabilities;
prioritize remediation;
update packages;
remove unused components;
apply patches;
monitor infrastructure images;
review third-party components; and
document risk acceptance where immediate remediation is not feasible.

Not every vulnerability presents the same risk. Remediation priority may depend on exploitability, exposure, data sensitivity, business impact, and available mitigations.

18. API and Webhook Security

Anchor may provide APIs, webhooks, and integrations.

Security measures may include:

authenticated requests;
scoped API credentials;
request validation;
rate limits;
permission checks;
webhook signatures;
replay protection;
timestamp validation;
secret rotation;
audit logs;
restricted callback endpoints; and
error handling that avoids unnecessary information disclosure.

Organizations and developers are responsible for protecting API keys and secrets, verifying webhook authenticity, using HTTPS endpoints, rotating compromised credentials, restricting access, validating payloads, handling errors securely, and removing access when an integration is no longer needed.

19. Livestream and Media Security

Anchor may use access controls and media-delivery protections to reduce unauthorized access to livestreams and recordings.

Measures may include:

authenticated Event access;
ticket-based access;
private or unlisted Events;
expiring links or tokens;
access checks;
media-delivery controls;
restricted recordings;
stream monitoring;
moderation;
content removal; and
anti-abuse controls.

No digital delivery system can completely prevent screen recording, copying, link sharing, or unauthorized redistribution.

Organizers are responsible for selecting appropriate Event privacy and access settings.

20. Payment Security

Payments are processed by third-party payment providers, including Paystack.

Anchor does not store complete payment card numbers or card security codes.

Payment-related security may include:

secure hosted payment interfaces;
payment-provider tokenization;
transaction references;
fraud monitoring;
webhook verification;
amount and currency validation;
duplicate-payment controls;
restricted payout changes;
reconciliation;
dispute records;
access controls; and
payment-provider compliance processes.

Payment providers may independently apply identity verification, transaction monitoring, risk holds, reserves, and fraud controls.

21. Data Protection

Anchor uses technical and organizational measures intended to protect Personal Information and other Platform data.

Measures may include:

data minimization;
access restrictions;
role-based permissions;
encryption;
retention controls;
secure deletion or anonymization;
environment separation;
logging;
monitoring;
backups;
privacy review;
controlled exports;
restricted administrative access; and
service-provider agreements.

Event organizers are responsible for the attendee information they collect through events hosted on Anchor. Anchor processes and stores this information to provide the Services, maintain platform security, comply with legal obligations, and improve our Services.

22. Logging and Monitoring

Anchor may collect and review security, operational, audit, and application logs.

Logs may include:

login attempts;
authentication events;
password resets;
administrative changes;
Organization membership changes;
payment events;
API activity;
webhook activity;
access failures;
suspicious requests;
infrastructure events;
application errors;
Event configuration changes; and
security alerts.

Logs may be used to investigate incidents, detect abuse, diagnose problems, support users, maintain audit trails, respond to legal requests, improve Platform reliability, and enforce policies.

Security logs are generally retained for 12 months unless a longer period is reasonably necessary.

23. Fraud and Abuse Prevention

Anchor uses security and risk controls intended to detect and prevent:

Account takeover;
credential abuse;
payment fraud;
fake Events;
ticketing fraud;
donation abuse;
spam;
malicious automation;
policy evasion;
suspicious API activity;
excessive requests;
unauthorized access; and
other misuse.

Controls may include rate limiting, identity verification, behavioral signals, transaction monitoring, device and network information, manual review, payment-provider checks, access restrictions, session revocation, content moderation, and Account suspension.

Fraud controls may produce false positives. Anchor may request additional information where activity requires review.

24. Backups and Recovery

Anchor maintains backups and recovery processes appropriate to its infrastructure.

Backup controls may include:

scheduled database backups;
encrypted storage;
restricted access;
geographic or infrastructure separation;
retention schedules;
restoration procedures;
integrity checks;
disaster-recovery planning; and
periodic review.

Backups are automatically overwritten according to infrastructure retention schedules.

Backups are intended for operational recovery and are not designed as a user-controlled archive.

Users and Organizations should retain their own copies of information they are required to preserve.

25. Availability and Resilience

Anchor uses infrastructure and operational measures intended to support availability and resilience.

These may include:

scalable cloud resources;
distributed infrastructure;
monitoring;
health checks;
restart and recovery procedures;
redundancy;
backup restoration;
capacity planning;
incident escalation;
dependency monitoring;
content-delivery systems; and
operational runbooks.

Availability may still be affected by maintenance, software defects, cloud-provider outages, internet disruptions, cyberattacks, excessive demand, third-party failures, power or telecommunications failures, natural disasters, legal restrictions, or other events beyond Anchor's reasonable control.

Unless expressly agreed in writing, this Security Overview does not establish a guaranteed uptime commitment.

26. Incident Response

Anchor maintains procedures for responding to suspected or confirmed security incidents.

Incident-response activities may include:

receiving or detecting an alert;
assessing severity and scope;
containing affected systems;
preserving relevant evidence;
investigating the cause;
removing malicious access;
restoring affected services;
validating recovery;
notifying affected parties where required;
documenting findings; and
implementing corrective actions.

Response priorities depend on the potential impact on confidentiality, integrity, availability, users, Organizations, and legal obligations.

27. Security Notifications

Where Anchor becomes aware of a security incident that materially affects Personal Information or Platform security, Anchor may notify affected users, Organizations, regulators, service providers, or authorities where required or appropriate.

A notification may include:

a description of the incident;
the approximate timing;
the information or systems affected;
steps Anchor has taken;
recommended user actions;
contact information; and
other legally required details.

Notifications may be delayed where disclosure would interfere with an investigation, increase risk, or violate lawful instructions.

28. Third-Party Risk

Anchor relies on third-party providers for infrastructure, payments, analytics, communications, authentication, and other functions.

Anchor may evaluate providers based on security practices, reliability, privacy terms, contractual protections, access to information, service criticality, geographic processing, incident procedures, availability, data-retention practices, and operational risk.

Anchor cannot eliminate all risk arising from third-party systems.

Providers may change their services, architecture, policies, or locations independently.

29. Employee and Contractor Security

Personnel with access to Anchor systems or information may be subject to controls appropriate to their role.

These may include:

confidentiality obligations;
access restrictions;
role-based permissions;
onboarding and offboarding procedures;
security awareness;
acceptable-use rules;
secure-device requirements;
multi-factor authentication;
access logging;
incident reporting; and
disciplinary procedures.

Access should be removed promptly when a person leaves or no longer requires it.

30. Customer Security Responsibilities

Users are responsible for:

choosing strong and unique passwords;
protecting authentication credentials;
enabling multi-factor authentication;
keeping devices and software updated;
using secure networks;
verifying links and messages;
reviewing active sessions;
protecting recovery methods;
reporting suspected compromise;
maintaining accurate contact information; and
avoiding the disclosure of sensitive information through insecure channels.

Users should not share Accounts where individual access can be assigned.

31. Event Organizer Security Responsibilities

Organizers should:

assign least-privilege roles;
review team access regularly;
protect attendee information;
use appropriate Event privacy settings;
verify payout changes;
secure streaming equipment;
protect Event access links;
remove former staff;
configure integrations securely;
moderate engagement tools;
respond to suspicious activity;
maintain Event-specific backups where appropriate; and
comply with the Organizer Terms.

An Organizer must notify Anchor promptly if it believes attendee data, Event data, credentials, payment details, or Organization systems have been compromised.

32. Security Testing and Vulnerability Reporting

Anchor may conduct internal or third-party testing appropriate to its risk and maturity.

Testing may include:

application testing;
infrastructure review;
configuration review;
dependency scanning;
authorization testing;
authentication testing;
code review;
security monitoring;
backup restoration testing; and
incident-response exercises.

Users and researchers must not conduct unauthorized testing against Anchor.

Suspected vulnerabilities should be reported to:

legal@technologies.aurelo.cc

A report should include:

the affected feature or URL;
a clear description;
steps to reproduce;
the potential impact;
relevant screenshots or logs;
the reporter's contact information; and
confirmation that the issue was not exploited beyond what was necessary to demonstrate it.

Researchers must not access unnecessary Personal Information, disrupt Services, modify or delete data, perform denial-of-service testing, use social engineering, publish the issue before Anchor has a reasonable opportunity to respond, or demand payment as a condition of not disclosing or exploiting the issue.

This Security Overview does not establish a paid bug-bounty program.

33. Data Retention and Deletion

Anchor retains information according to its documented retention practices.

Data Category	Standard Retention Period
Active Account information	Until the Account is deleted
Soft-deleted Account information	Up to 30 days
Transaction and billing records	7 years, or longer where required by law
Security logs and audit records	12 months, unless longer retention is reasonably necessary
Event analytics	Until deleted by the relevant Organization
Backups	Automatically overwritten according to infrastructure retention schedules

Information may be retained longer where required for legal obligations, security investigations, fraud prevention, dispute resolution, or legal claims.

For more information, see the Privacy Policy and Account Deletion Policy.

34. Artificial Intelligence Security

Anchor may use artificial intelligence features for moderation, recommendations, search, transcription, summarization, analytics, and automation.

AI-related security measures may include:

access controls;
input validation;
moderation;
logging;
usage limits;
review of output risks;
restricted handling of sensitive information;
provider review;
monitoring for abuse;
human oversight; and
limitations on consequential use.

Users should not enter passwords, authentication tokens, complete payment card information, confidential legal information, or unnecessary sensitive Personal Information into AI features.

AI outputs may be inaccurate, incomplete, or manipulated by malicious input.

Users and Organizations remain responsible for reviewing outputs before acting on them.

35. Physical Security

Anchor primarily relies on cloud infrastructure providers for physical data-center security.

Those providers generally control:

facility access;
surveillance;
environmental systems;
hardware disposal;
power;
cooling;
fire suppression;
physical network security; and
on-site personnel.

Anchor personnel are responsible for protecting company devices, offices, workspaces, and physical records under their control.

36. Compliance and Assurance

Anchor's security program may be informed by recognized security and privacy principles.

However, unless expressly stated in a current written publication or contract, Anchor does not claim to hold a particular certification, audit report, or regulatory approval.

The absence of a listed certification does not mean that Anchor lacks security controls, and the presence of a control does not mean that Anchor has been independently certified.

Any future certifications, audit reports, or assurance materials should be listed accurately in the Trust Center only after they have been formally obtained.

37. Limitations

Security controls reduce risk but cannot eliminate every threat.

Anchor cannot guarantee that:

the Platform will never experience a vulnerability;
unauthorized persons will never obtain access;
all malicious activity will be detected;
every third-party service will remain secure;
every user will configure features correctly;
every livestream will remain private;
every Account takeover attempt will be prevented; or
every incident will be resolved without impact.

Nothing in this Security Overview expands or replaces the disclaimers, limitations, and liability provisions in the Terms & Conditions.

38. Changes to this Security Overview

Anchor may update this Security Overview to reflect changes in Platform architecture, infrastructure providers, security controls, authentication methods, incident procedures, data-retention practices, payment services, artificial intelligence features, legal requirements, or operational experience.

When changes are made, Anchor will revise the Last Updated date.

Material security changes may also be recorded in the Trust Center Changelog where appropriate.

39. Contact

Security questions and suspected vulnerabilities may be directed to:

Aurelo Technologies
Accra, Ghana

Security and legal: legal@technologies.aurelo.cc
Support: support@technologies.aurelo.cc
Telephone: +233 532 396 876

For urgent Account compromise, users should contact Support promptly and change affected credentials where possible.