Security Controls That Map to ISMS and SOC 2 in Your Core Business System

It is the Monday after a long weekend. Your accounting lead logs in from home to close the books, and somewhere in the back of your mind a question repeats. Is the financial data sitting in your core business system actually protected the way your auditor will soon expect it to be?

For most Japanese mid-market companies, that question used to be hypothetical. It is not anymore. Customers now send security questionnaires before signing. Banks ask about access controls before lending. And regulators, especially after the personal data breach reporting rules tightened, want to know who could see what, and when.

This post looks at the security controls that genuinely matter in a core business system, how they map to two familiar frameworks (ISMS, the ISO 27001 family, and SOC 2), and where the honest gaps still live. The point is not to chase a badge. The point is to know, before the audit, which controls you already have working and which ones you must build a process around.

Why security is now a board-level question in Japan

Two numbers explain the shift. In FY2023, Japan's Personal Information Protection Commission processed 12,120 personal-data leak reports, roughly 60% more than the prior year (PPC annual report). That is a volume that no compliance team can ignore. Separately, Japan saw 222 reported ransomware incidents during 2024, with many cases taking more than a month to resolve.

The 2025 legacy cliff adds fuel. Companies that have delayed renewing on-premise systems built 20 years ago now face two pressures at once. They must modernize to keep running, and they must modernize without inheriting a weaker security posture than the old system had. Succession planning and the labor shortage mean fewer veteran operators are around to babysit brittle, custom access rules.

ISMS and SOC 2 are how many of these buyers express the requirement out loud. ISMS (an information security management system, most often certified to ISO 27001 or JIS Q 27001) is widely recognized in Japan, especially by government and large enterprise customers. SOC 2, developed by the AICPA, is the language most global SaaS vendors and their auditors speak. The two frameworks overlap heavily on the controls that concern a core business system: access management, logical access, change control, monitoring, and the simple ability to prove who did what.

A core business system cannot deliver certification by itself. Certification is an organizational effort covering people, process, network, and physical controls. But the software you run daily can either make the controls easy to evidence, or make them a paperwork nightmare. That is the gap this post is about.

What "good" looks like, in plain controls

Before mapping anything to a framework, it helps to list the controls a non-technical owner can actually recognize. The Kikan System team built each of the following into the platform, and each shows up in the code as a real, enforceable rule rather than a policy someone is supposed to remember.

Passwordless login with passkeys. Staff can register a passkey on their device and sign in without typing a password. The system generates a per-session challenge, verifies the device's cryptographic response, and records the authenticator with a label and a last-used timestamp. Users can list their registered devices, rename them, and delete the ones they no longer trust. This removes the single biggest cause of account takeover, which is reused or phishable passwords.

Two-factor authentication. For accounts that still use passwords, the system supports time-based one-time codes, with QR setup and recovery codes. Passkey login and two-factor can be combined, so even a stolen credential set cannot complete a login.

Password history aligned to NIST guidance. The platform prevents reuse of the last five passwords, stores hashes only, and enforces a minimum age before a password can be changed again. That mirrors NIST SP 800-63B rather than the older, less effective complexity-and-expiry rules many Japanese firms still carry over.

Access granted by role. Permissions are not granted per individual in a flat list. They are attached to roles, and each role carries a permissions map covering specific resources and actions (view, create, edit, delete). A finance clerk can see invoices but cannot delete a role. An IT administrator can manage roles but cannot approve their own purchase order. System roles are protected from rename or deletion, and changes use optimistic locking so two administrators cannot silently overwrite each other.

IP restrictions. Each company can restrict sign-in to approved networks. The control supports three match types: a single address, a CIDR range, and a start-to-end range, for both IPv4 and IPv6. Enforcement runs in two modes. Allow mode admits only listed addresses. Deny mode blocks listed addresses and admits the rest. The toggle is per company, so a manufacturer can lock the back office to the factory network while field staff use a narrower allowlist.

Each company keeps its data fully isolated. Every request resolves to one company's context, and data access is scoped to that context. One company's invoices, journals, and inventory records are not visible to another, even when both run on the same platform instance.

Session management and token theft detection. Refresh tokens rotate on each use, following current token-rotation guidance. The platform tracks active sessions per device, and when a password change, role change, or account deactivation happens, it invalidates tokens in bulk so a stale device cannot keep reading data. A built-in theft-detection flag marks suspicious token reuse for revocation.

A record of who did what, and when. Sensitive actions are audit-logged at the point of action. Deleting an IP restriction, for example, records the operator, the operation, and a timestamp. For approvals, the workflow engine captures the request, the definition, and each step. You do not need a separate spreadsheet to prove an action was authorized.

How those controls map to ISMS and SOC 2

Frameworks describe outcomes; the code above delivers them. Here is the honest mapping an auditor would recognize.

ISMS (ISO 27001) Annex A organizes controls into themes. Logical access control (A.5.15), authentication (A.5.17), access rights (A.5.18), and information access restriction (A.8.3) all map directly to role-based access and per-company isolation. The passkey and two-factor controls satisfy strong authentication expectations. The IP restriction feature supports networks security (A.8.20) and secure log-in procedures. The audit trail of who-did-what supports logging and monitoring (A.8.15). Password history aligned to NIST supports the asset and authentication lifecycle.

SOC 2 Trust Services Criteria take a slightly different shape but reach the same place. The Common Criteria require logical and physical access controls (CC6.1, CC6.2, CC6.3). Role-based access, per-company isolation, and session revocation cover access provisioning, modification, and removal. Passwordless and two-factor authentication map to identification and authentication. Logging sensitive actions supports CC7.2, the monitoring of system performance and security events.

Neither framework will hand you a certificate because these features exist. What the features do is remove the most common, most expensive audit findings before the auditor arrives: shared logins, no role boundaries, no network restriction, no session revocation, and no traceable record of privileged actions.

A scenario: the precision parts maker in Higashi-Osaka

Picture a precision parts manufacturer in Higashi-Osaka, about seventy staff, doing roughly 1.8 billion yen a year in revenue. Their largest customer, an automotive Tier 1 supplier, sent a 90-question security questionnaire last quarter and gave them six months to answer it credibly.

Before renewal, access was a folk system. The previous IT manager had created one shared administrator account "to keep things simple." Two people knew the password. Three more had learned it by watching. Month-end close meant email attachments moving between the accounting PC and a sales laptop. The IP-restriction policy was a printed sheet taped to a server cabinet that nobody had opened in two years.

After moving finance, inventory, and sales onto the platform, the picture changed in concrete ways. The shared administrator account was retired. Each staff member signs in with a passkey tied to their own device. The accounting team's access is scoped to a role that can post journal entries and run reports but cannot change a role or delete master data. The factory network is set as an allowlist for the back-office login, so a credential phished off a personal phone still cannot reach the books from an unknown network. When an operator left the company in March, deactivating their login revoked their sessions across every device in one step, with a timestamped record of who performed it.

The scenario's lesson is not that the platform passed an audit. It did not, on its own. The lesson is that the controls an auditor will test, the ones that take weeks of evidence-gathering in a spreadsheet-driven company, were already in place and observable the day they switched on.

The honest gaps, and how to close them

A trustworthy post names what is missing. Here is what the platform does not do today, and what a buyer should plan for.

The platform is not ISMS or SOC 2 certified. Certification is an organizational commitment, not a software feature. Treat certification as a roadmap goal. The controls above give you a strong head start on the technical controls, but you will still need documented policies, risk assessment, network and physical controls, and an external auditor.

There is no dedicated, immutable audit-log table. Sensitive actions are recorded at the point of action, and the approval workflow engine captures each step. But a long-retention, tamper-evident log store built for forensic review is not a feature today. If your auditor requires a separate, immutable log repository, plan to export the action records on a schedule into a write-once store.

Multi-currency and exchange-rate handling is not built. This is not strictly a security control, but it often appears on security and finance questionnaires because it affects how monetary exposure is reported. If you operate across currencies today, expect to handle that manually until it ships.

Certified storage for electronic bookkeeping law is not provided. The system stores transaction data well, but it is not a certified archive under the electronic bookkeeping preservation rules. Keep your archival process separate.

These gaps are framings, not failures. A platform that quietly omits them and lets buyers assume otherwise is the real risk. Naming them up front is how a buyer builds a realistic roadmap to certification.

Frequently Asked Questions

We cannot afford to rip out our current system just for better security.

You do not have to. The controls described here are about access, identity, and visibility, not about migrating every historical record on day one. Many companies phase the rollout, finance and inventory first, then purchasing, then CRM, and the security posture improves as soon as the first set of users is on passkeys and role-based access, well before the old system is fully retired.

Will auditors accept a system that is not itself certified?

They will, if you can evidence the controls. Auditors test whether a control is designed and operating effectively, and role-based access, per-company isolation, IP restriction, session revocation, and an action trail are all testable. What they will not accept is a vendor that claims compliance without evidence, so keep the action logs, the role assignments, and the IP allowlist configurations, and your auditor has something concrete to examine.

How do we handle a departing employee quickly?

Deactivate the login. The platform revokes every active session for that user in one action, across all devices, and records who performed the deactivation and when. Their role permissions stop applying immediately, so there is no need to track down laptops or change a shared password.

What about staff who insist on passwords?

Passkeys are recommended but not the only path. Two-factor authentication covers password-based logins, and password history prevents reuse. Let hesitant staff keep passwords behind a second factor while you migrate the willing to passkeys, and adoption spreads once people see how fast passwordless login is, with the free plan covering up to 2 users and no credit card required to pilot it in Kikan System.

Key takeaway: certification is earned through evidence, and the controls worth certifying are the ones your team uses every working day.

Closing the gap before the audit

Security in a core business system is not a marketing slide. It is a set of small, enforceable rules that either exist in the code or do not. Passkeys that replace phishable passwords. Access granted by role rather than by a shared account. IP restrictions that stop a stolen credential from an unknown network. Each company keeping its data fully isolated. Sessions that vanish the moment an operator leaves. A trail of who did what.

Kikan System ships each of those controls as a real feature. We are upfront that the platform itself is not ISMS or SOC 2 certified, and that certification is a roadmap goal that also needs your people, your policies, and an external auditor. What we give you is the technical foundation that makes the certification effort shorter, cheaper, and far less painful than starting from a spreadsheet and a taped-up network diagram.

If your largest customer has just sent the security questionnaire, start here. See the controls running in your own company, with your own roles and your own people, before you commit to anything.

Start free with Kikan System, up to 2 users, no credit card. See /#pricing for plan details.

-> Related: JSOX Approval Workflows