Security Policy
Last Updated: April 1, 2026
Section 1. Governing Principles
We manage SmoothQ as a service with high public relevance and therefore balance confidentiality, integrity, availability, and traceability as the core principles of our security governance. Security is treated as a continuous control function spanning management, operations, engineering, legal review, support, and vendor oversight rather than as an isolated technical task.
Section 2. Scope
This Policy applies to public website functions, authentication, administration interfaces, APIs, logs, monitoring, backups, development and test environments, and outsourced operations involved in SmoothQ. Where a component is outside our direct control, such as an external provider or facility-side system, we mitigate risk through contractual controls, configuration, monitoring, and alternate measures where feasible.
Section 3. Legal and Reference Standards
We operate with reference to the Act on the Protection of Personal Information, the Unauthorized Computer Access Prohibition Act, the Basic Act on Cybersecurity, the Telecommunications Business Act, and other applicable Japanese requirements. We also review public guidance from NISC, IPA, and other authoritative bodies and use those materials as references when updating internal standards and operational controls.
Section 4. Encryption in Transit
Public communications are protected with TLS 1.3 as the preferred baseline, with TLS 1.2 permitted only where compatibility requires it. Plaintext transmission of credentials, outdated protocols below TLS 1.2, weak cipher suites, and improper certificate settings are not adopted as a general rule. Authentication cookies are configured with Secure and SameSite protections as part of session hijack and tampering resistance.
Section 5. Protection of Stored Data
For stored data, we combine encryption at rest using AES-256-equivalent controls where appropriate, access control, key handling, segregation of secrets, and encrypted backups according to data sensitivity. Tokens, environment variables, API credentials, inquiry records, and audit logs are handled in controlled storage areas and we avoid unnecessary commingling across development, testing, and production contexts.
Section 6. Identity, Authentication, and Authorization
Access is governed by least privilege, separation of duties, and need-based assignment. Administrative and other high-privilege operations are subject to role-based control, strengthened authentication or compensating safeguards, operational logging, periodic entitlement review, and timely removal of unnecessary permissions. Shared accounts used as a convenience, unattended privileges, or rights beyond operational necessity are not accepted practices.
Section 7. Network and Application Defense
We employ layered controls including firewalls, rate limiting, security headers, input validation, CSRF protections, cookie attribute hardening, dependency updates, login-throttling controls, and monitoring. Abnormal traffic, mass requests, brute-force attempts, abusive crawling, and other potentially hostile patterns may be blocked, constrained, or escalated for investigation.
Section 8. Secure Development
Security is considered from requirements through release. We review data classification, permission boundaries, validation and escaping, dependency risk, logging design, and secret handling before and during implementation. Code review includes correctness, regression risk, XSS, CSRF, authorization, error handling, and leakage considerations, and releases are expected to pass build, lint, type-check, and relevant test gates before deployment.
Section 9. Vulnerability Management
We monitor dependency advisories, conduct configuration review and vulnerability scanning, maintain awareness of exposed assets, and supplement automated findings with manual analysis. High-severity issues are prioritized for emergency containment, configuration change, remediation, or compensating controls. As an operational benchmark, we seek to make remediation decisions within 72 hours for urgent issues, within 14 days for high-severity issues, and within 30 days for medium-severity issues.
Section 10. Logging, Monitoring, and Evidence Preservation
Authentication events, permission changes, administrative operations, API anomalies, rate-limit violations, incidents, and other important activities are logged to the extent reasonably necessary. Logs are retained under access control and anti-tamper measures, generally for between 180 and 365 days, depending on purpose. When suspicious activity is detected, we seek to preserve evidence, assess scope, and escalate according to impact.
Section 11. Backup, Availability, and Recovery
To prepare for failure, error, disaster, or malware-driven data loss, we maintain encrypted backups, restoration procedures, configuration preservation, and availability monitoring. Backup schedules are set according to operational need, with a standard retention target of up to 35 days. Significant incidents are handled through impact assessment, temporary restoration, permanent remediation, and post-incident review.
Section 12. Vendor and Service Provider Management
When using cloud infrastructure, email systems, monitoring services, or assessment providers, we review the provider's security posture, subcontracting controls, incident reporting commitments, data location, auditability, and end-of-service deletion or return procedures. Appropriate confidentiality, access, breach reporting, and security obligations are addressed contractually and revisited over time.
Section 13. Incident Response
When an incident is detected, we follow a structured sequence of triage, containment, evidence preservation, root-cause analysis, temporary recovery, permanent corrective action, reporting, and recurrence prevention. If personal data may be affected, we evaluate reporting and notification obligations in accordance with law and our Privacy Policy. Significant incidents are also used to update standards, monitoring, or engineering controls.
Section 14. Vulnerability Reporting and Disclosure
We accept good-faith reports relating to security issues from users, researchers, and other stakeholders, provided they are made through lawful means and without service disruption, unauthorized acquisition, or harmful disclosure. Whether and when to disclose a vulnerability or incident publicly is determined by considering exploitability, remediation status, user protection needs, and the risk of further abuse.
Section 15. Continuous Improvement
We continually review security controls based on audit outcomes, incident analysis, user reports, and evolving threat intelligence. Written rules alone are not considered sufficient; effectiveness must be tested through operation, review, training, and exception management. This Policy may be revised as the Service evolves or as legal and technical expectations change.
Section 16. Security Contact
Questions or reports relating to vulnerabilities, suspected unauthorized access, accidental disclosure, or other security concerns may be sent to the contact point below. We aim to acknowledge receipt promptly and investigate according to impact and urgency, requesting additional information where needed.
Operator
JPSM Group Supervising Operations Executive: Haruki Ogasawara Locations: Tokyo / Okayama / Ibaraki Contact: contact@smoothq.jp
SmoothQ: https://smoothq.jp/