Privacy
Data minimisation, approved sources and project-specific processing boundaries.
Trust
Security & Data Handling
ITYES IT FACTORY S.R.L. · Last updated: July 6, 2026
This page describes the security and data-handling approach ITYES applies when designing custom software, integrations, automation and enterprise AI systems. Specific controls depend on the project scope, environment and client requirements.
1. Design Principles
- Least-privilege access for people, services and tools.
- Clear separation between public website interactions, project discovery and production client systems.
- Human approval for important AI-generated actions.
- Logging and traceability where the workflow requires audit review.
- Compatibility checks before connecting to enterprise systems.
1.1 Enterprise Security Scope
Compliance
GDPR-aware handling and documented responsibilities for controller / processor roles.
Audit
Logs for tool calls, approvals, operator actions and integration events where implemented.
Identity
Access model review, least privilege and role boundaries before production use.
RBAC
Role-based access control can be scoped for operator, admin and integration permissions.
Encryption
Transport encryption and data-at-rest options depend on the selected hosting and storage model.
Data residency
Deployment and storage locations are defined during project scoping when required.
Readiness
ISO 27001 / SOC 2 readiness support can be discussed; this page does not claim certification.
2. Enterprise Integrations
Integrations with ERP, SAP, Salesforce, Microsoft Dynamics, internal databases, legacy systems and custom APIs are assessed per project. Before implementation, ITYES reviews available APIs, authentication model, data fields, access boundaries, environment options and rollback or manual fallback needs.
3. AI, RAG and Tool Calling
For AI systems, ITYES defines what the agent can read, what tools it can call, what actions require human approval, and what logs must be retained. RAG is scoped to approved sources. MCP, tool calling, LangGraph-style workflows and observability tools such as LangSmith may be used when they fit the security and operational requirements.
4. Credentials and Secrets
Production credentials should not be sent through public chat, email threads or website forms. For project work, credentials are handled through agreed secure channels or client-managed access. Access should be revoked when no longer required.
5. Logs, Audit and Analytics
Where implemented, logs may include integration events, agent decisions, tool calls, source references, approval status, operator actions and system errors. Analytics is used to understand operational performance, not to create hidden automated decisions about individuals.
6. Data Environments
When appropriate, ITYES separates development, staging and production environments. Test data, synthetic data or anonymised data is preferred during discovery and early prototyping. Production data use should be explicitly approved.
7. Incident Handling
If a security or data incident is suspected, ITYES prioritises containment, investigation, client notification, evidence preservation and remediation. Contractual incident procedures may define specific notification timelines and responsibilities.
8. What We Do Not Claim
Unless explicitly agreed and verified for a project, ITYES does not claim ISO 27001 certification, SOC 2 certification, sector-specific compliance certification or guaranteed compatibility with every enterprise system. Security commitments should be stated in the project contract.
9. Contact
For security or data-handling questions, contact contact@ityes.eu.