ORGNavi Security Policy

All data is transmitted in encrypted form via SSL/TLS. HTTP requests are automatically redirected to HTTPS.

Sensitive data stored on our servers is encrypted at rest.

Data is backed up regularly and can be restored quickly in the event of a failure.

Each customer's data is managed in a completely separate database, structurally preventing data cross-contamination. (On-premise ORGNavi)

An account belonging to Customer A cannot access Customer B's data. Strictly enforced at the application level.

Features and data are granularly controlled by role — Administrator, Editor, and Viewer.

Sessions automatically expire after a period of inactivity, preventing threats from unattended sessions.

Accounts are temporarily locked after consecutive failed login attempts to defend against brute-force attacks.

Supports OTP-based 2FA via Google Authenticator. Even if a password is leaked, access is blocked without the second factor.

Supports login via social accounts such as Google, leveraging the security infrastructure of those platforms.

All ORGNavi services run on the AWS Seoul region (ap-northeast-2). Customer data is processed and stored domestically, supporting local compliance requirements and delivering low latency.

We use AWS RDS (Relational Database Service) for database operations. Automatic backups, Multi-AZ redundancy, and automatic patching provide structural stability through AWS-managed infrastructure.

Databases and internal services run exclusively inside a VPC (Virtual Private Cloud) isolated from the public internet. Direct external access is structurally impossible.

AWS Shield provides defense against abnormal high-volume traffic attacks.

Customer administrators can register permitted IP addresses. Access from unregistered IPs can be blocked or require additional authentication.

All database queries use parameterized binding, fundamentally blocking SQL injection attacks.

Thorough validation and escaping of user input prevents cross-site scripting attacks.

All API requests undergo token validation. Token expiry and refresh policies minimize the risk of stolen token abuse.

Security vulnerabilities are scanned and patched on a regular basis.

A complete record of who logged in, when, and from where is maintained.

Administrators are alerted when anomalies are detected, such as new IPs or logins at unusual hours.

A dedicated server instance is operated separately for large enterprises and security-sensitive customers. Multiple affiliates can be managed in a single instance.

A VPN tunnel is configured between the dedicated instance and the customer's internal network. Access from outside the customer's network is structurally blocked.

Installed directly on the customer's own servers. All data operates entirely within the customer's environment, eliminating the risk of external leakage.