Receive only necessary data
We first check whether names, addresses, contact details, free text, and full datasets can be removed. Small anonymized samples are preferred before bulk data.
Security & Data Handling
Handle entrusted data
without ambiguity.
We define which data is handled, for what purpose, by whom, in which environment, and for how long. From mathematical prototypes to production operations, boundaries and responsibilities are agreed first and kept as reviewable evidence.
We do not claim perfect safety.
This page does not claim a certification.
Project-specific agreements come first.
DATA CONTROL PLANEPROJECT / 001
01CustomerSource data and business rules
Minimum needed
02FINITE FIELDDesign, development, verification
Agreed scope
03Services usedCloud and external integrations
PurposeDefined in advance
AccessLimited to necessary people
StorageLocation and period agreed
DeletionMethod and evidence decided
DESIGN BEFORE TRANSFERReceive after boundaries are set
Our position
We publish decision material, not vague reassurance.
Security is not determined by a product name or a single feature. We design around data type, purpose, organization, operations, and subprocessors, then keep the implemented scope reviewable.
Define boundaries before transfer
Storage location, viewers, external services, AI use, retention, and deletion are agreed before data receipt or production transition.
Leave reviewable artifacts
Data flows, access rights, subprocessors, backup, deletion, and incident contacts are kept as artifacts that can be checked.
What we publishPolicy, design items, and reviewable artifacts
What each project decidesSpecific services, permissions, retention, and test scope
What we do not publishSecrets or detailed settings that could help an attacker
Data journey
Decide each stage from receipt to deletion.
The same data requires different controls for diagnosis, prototypes, and production operations. We separate what is received, what must be decided, and what evidence remains.
INTAKE
Start with explanation materials and anonymized samples.
Prefer low handling volumeExamples received
- Current spreadsheet columns
- A few fictional or anonymized rows
- Business rules and pain points
- Metrics to improve
Decide in advance
- Whether real names are necessary
- How attachments are sent
- Who handles the consultation
- Retention after consultation
Artifacts kept
- Received data list
- Purpose memo
- Deletion target date
- Open questions
PROTOTYPE
Minimum data to test whether the problem can be solved.
Design isolated validationExamples received
- Staff, case, or equipment identifiers
- Time, qualification, capacity, and order
- Current plan and metrics
- Exception samples
Decide in advance
- Pseudonymization method
- Validation environment and viewers
- External AI use
- Deletion or continued use after delivery
Artifacts kept
- Data dictionary
- Constraint list
- Environment and access table
- End-of-validation handling record
DEVELOPMENT
Fix roles and boundaries for production data.
Design review requiredExamples received
- Production-equivalent data structure
- Users, permissions, and organization data
- External integration specs
- Audit and backup requirements
Decide in advance
- Environment separation and secrets
- Least privilege and authentication
- Log scope and retention
- Testing and review scope
Artifacts kept
- Data flow diagram
- Access matrix
- External service list
- Pre-release review record
OPERATION
Prepare to detect, respond, and recover, not only protect.
Continuous operation requiredExamples received
- Accounts and permissions
- Logs and alerts
- Backups
- Dependencies and updates
Decide in advance
- Monitoring and response hours
- Change and access reviews
- Recovery objectives
- Incident contact path
Artifacts kept
- Operations procedure
- Backup test record
- Access review record
- Incident and change history
DELETION
Decide handling even after the project ends.
Confirm deletion scopeExamples received
- Working copies
- Shared storage
- Backups
- Logs, tickets, and attachments
Decide in advance
- Return or deletion
- Legal and contractual retention
- Backup deletion timing
- Evidence format
Artifacts kept
- Target list
- Deletion date
- Exceptions and remaining reason
- Completion confirmation
Security profile builder
Organize a project-specific design draft in about two minutes.
This is a design aid for the first meeting, not an audit or guarantee. No contact details are required.
Step 01 / Data class
Select data that may be handled
The draft is based on the category that needs the most careful handling. Multiple selections are allowed.
Step 02 / Delivery phase
Which phase are you considering?
Short validation and production operation require different controls even for the same data.
Step 03 / External processing
External AI and services
Cloud, mail, maps, analytics, and notification services are reviewed with the same data-flow thinking.
Step 04 / Operational needs
Select required operational needs
Multiple selections are allowed. Even uncertain items are included as meeting topics.
Design draft / not an audit
Limited prototype design
Start with minimum data, short retention, and a separated validation environment.
ProfileSTANDARDP0-B
Minimum controls
Project decisions
Artifacts to prepare
How to read this result:
This is a preliminary design draft from the selected inputs. Final controls are decided after legal duties, contract terms, threats, cloud architecture, and operations are confirmed.
Control model
Cover detection, response, and recovery, not only prevention.
We reference the six NIST Cybersecurity Framework 2.0 functions as project review viewpoints. This is not a certification or full compliance claim.
Govern
GOVERNClarify owners, policy, contracts, subprocessors, and acceptable risk.
Example: responsibility table, service listIdentify
IDENTIFYUnderstand assets, data, dependencies, threats, and impact.
Example: data flow, asset registerProtect
PROTECTDesign authentication, least privilege, encryption, secrets, and secure implementation.
Example: permission matrix, implementation checkDetect
DETECTDefine required logs, monitoring, alerts, and anomaly criteria.
Example: monitoring items, log retentionRespond
RESPONDPrepare triage, containment, investigation, communication, and prevention.
Example: contact tree, first-response procedureRecover
RECOVERDesign backup integrity, recovery order, business restart, and follow-up review.
Example: recovery runbook, test recordApplication security
For web and apps, check from design through operation.
We use OWASP ASVS 5.0 as a reference for security requirements and verification items. Review, automated checks, manual checks, and external testing are combined according to importance and budget.
- 01Requirements and threatsOrganize data, permissions, attack surface
- 02ImplementationAuthentication, input, secrets, dependencies
- 03VerificationReview, testing, configuration check
- 04OperationMonitoring, updates, permissions, recovery
Prototype vs production
We do not treat prototypes and production the same.
This comparison shows design criteria to finalize per project, not fixed guarantees.
| Review item | P0 mathematical prototype | P1 production system |
|---|---|---|
| Purpose | Validate feasibility and metrics | Continuous business processing |
| Data volume | Prefer small, anonymized, necessary fields | Formally define required operational scope |
| Environment | Separate a short-term validation environment | Consider development, test, and production separation |
| Access | Limit to assigned people | Role permissions, authentication, reviews |
| External AI | Start from a design that does not send unnecessary data | Agree purpose, target, contract, settings, logs |
| Retention | Decide end date first | Consider purpose, law, operations, backups |
| Deletion | Confirm deletion or continued use after delivery | Design account exit, contract end, legal retention, backups |
| Recovery | Assess whether it can be recreated | Set recovery objectives and backup tests |
Shared responsibility
Separate who protects what before contract.
Cloud use does not automatically make everything safe, and a developer cannot manage every risk alone. We separate the roles of the customer, Finite Field, and services used.
OUR SCOPE
Design, implementation, and development operations
Within the contracted scope, we handle system controls and development-time data handling.
- Data flow and permission design
- Secure application implementation
- Secrets and development environment management
- Agreed testing and review
- Monitoring, updates, and response within maintenance scope
CUSTOMER SCOPE
Business, users, and data responsibilities
Lawful data use, user and endpoint operations, and internal rules remain important customer responsibilities.
- Purpose and validity of input data
- User registration, offboarding, and permission requests
- Endpoints, internal network, and sharing method
- Reporting suspicious events and business decisions
- Return or deletion instruction at contract end
PLATFORM SCOPE
What platform services cover
Physical facilities, platform services, and managed-service scope follow each service contract and shared responsibility model.
- Data centers and infrastructure
- Service availability and updates
- Platform access and encryption features
- Contractual storage and processing conditions
- Service incident and security information
Items to make explicit in the contractOperatorMonitoring hoursBackupRecovery workInquiriesEnd-of-use handling
AI & third parties
Do not make external AI an invisible subprocessor.
When data goes to generative AI, maps, mail, analytics, notifications, payment, or other services, the purpose and scope are included in the data flow.
Do not send
Do not send business data to external AI. Use ordinary algorithms, local processing, or fixed anonymized data.
First option to considerSend limited data
Send only agreed fields to agreed services after identifiers are removed. Check whether transfers can be recorded.
Requires anonymization and minimizationSend within approval
Confirm service terms, retention, region, reuse conditions, and permissions, then document target data.
Needs individual risk judgmentEXTERNAL SERVICE CHECK
What to confirm per external service
- 01Data sentFields, frequency, volume
- 02PurposeProcessing, notification, analysis
- 03Retention and reuseStorage, learning, logs
- 04Location and subprocessorsCountry, region, supply chain
- 05Stop and deleteEnd-of-use handling
Incident response
Plan what happens if an incident occurs.
Before production operation, define event scope, contacts, first notice, containment, recovery, and prevention responsibilities.
Detect and receive
Detect events from monitoring, user contact, or service notices.
Contain
Reduce spread and preserve necessary evidence.
Analyze and decide
Confirm affected data, cause, impact, and reporting need.
Communicate and respond
Contact stakeholders based on law, contract, and situation.
Recover and improve
Recover after safety is confirmed and apply prevention.
Before productionEmergency contact
Before productionEvent scope
Before productionFirst notice path
Project designMonitoring and response hours
Law and contractNotification and reporting
Evidence pack
Make implemented work reviewable.
Depending on importance and contract scope, these artifacts can be created or updated. They are not all standard deliverables, so select what is needed during estimation.
CSV / 01
Data inventory
Fields, purpose, sensitivity, location, owner.
Download CSV / 02Data flow register
Source, destination, purpose, method, subprocessor.
Download CSV / 03Access matrix
Role, environment, operation, approval, review.
Download CSV / 04External service register
Service, purpose, data, location, contract.
Download CSV / 05Retention and deletion register
Reason, deadline, deletion method, evidence, exception.
Download CSV / 06Incident contact sheet
Event class, primary contact, fallback, decision owner.
Download CSV / 07Backup restore test
Target, recovery point, elapsed time, result, issue.
Download CSV / 08Requirements checklist
Design, implementation, testing, operation, exit handling.
Download CSV / 09AI and external service decision table
Purpose, sent fields, retention, approval, stop procedure.
DownloadRequest
Discuss questionnaires Support customer questionnaires
We answer customer security check sheets after confirming actual practices and project scope. Not-yet-implemented items are stated as such, with alternatives separated.
References
References and what we do not claim.
We use laws, public guidelines, and open standards as references when selecting controls for a project. Referencing them is separate from claiming certification or full compliance.
Japan privacy law and PPC guidelines
Used as a basis for checking safety management measures, handling rules, organizational, human, physical, and technical measures, and external environments.
Open official sourceNIST Cybersecurity Framework 2.0
The six functions are used as common language for risk and operational gaps.
Open official sourceOWASP ASVS 5.0
Used as a reference when organizing web and application security requirements and verification items.
Open official sourceThis page alone does not mean the following.
ISO/IEC 27001 certificationPrivacyMark certificationFull NIST CSF complianceOWASP ASVS certificationGuarantee of no incidentsSame controls for every projectFAQ
Common questions about data handling.
Do diagnosis or prototypes require production data?
In principle, we first check whether validation can use minimized anonymized or pseudonymized samples. If real data is necessary, scope, storage, viewers, and deletion timing are agreed in advance.
Do you send data to external generative AI?
External AI use, sent data, purpose, and retention are decided per project. A configuration that sends no business data to external AI can also be selected.
Can storage country or region be selected?
We check location requirements within the capabilities of the cloud or external services used. When cross-border transfer matters, services and data flows are made explicit.
What happens to data and source code after delivery?
Ownership, storage, access, backup, and deletion responsibilities are clarified according to contract, operating model, and maintenance scope.
Do you hold a security certification?
This page does not claim a specific certification. Controls and review artifacts are defined per project, and customer check sheets can be answered when needed.
When are incidents communicated?
Contacts, event scope, first notice method, and update frequency are decided before production operation. Actual notices follow law, contract, and event details.
Can you handle medical, care, or other sensitive data?
Necessity, legal requirements, access scope, storage, logs, deletion, and subprocessors must be checked. Stricter design is required and feasibility is decided per project.
Can we request security testing or vulnerability assessment?
Depending on target and required level, design review, automated checks, manual checks, and external specialists can be combined. Scope and deliverables are specified during estimation.
Next step
First, separate the data that can be shared from data that should stay out.
Before sending an entire workbook, you can start with column names or anonymized samples. We will sort out the required controls and development scope together.
Start the diagnosis Discuss data handling Please confirm the transfer method before sending confidential information.