Security

Security is a property of how software is built and operated, not a feature added at the end. We treat it as an engineering constraint from the first design conversation: what data exists, who can reach it, what happens when a component fails, and how we would know.

• Review on every change. Changes reach a main branch through review. Nobody pushes to production branches directly.
• Separated environments. Development, staging and production are isolated, with separate credentials. Production data is not copied into development or test environments; where realistic data is needed, it is anonymised or synthetic.
• No secrets in source. Credentials, keys and connection strings live in the environment or a managed secret store, never in the repository. Secrets are rotated when someone leaves a project and when we suspect exposure.
• Dependencies kept current. We track advisories for the libraries we ship and apply security updates promptly, weighing the risk of the vulnerability against the risk of the change.
• Least privilege in infrastructure. Services get the narrowest permissions that let them work. Infrastructure is defined as code so that what is running is reviewable and reproducible.
• Encryption in transit and at rest. Traffic is served over TLS. Data stores are encrypted at rest using the platform’s managed encryption.
• Logging and audit trails. Systems we build record who did what and when, at a level appropriate to the data they hold, and we design that in rather than bolt it on.

• Named accounts and multi-factor authentication. Every person has their own account. Shared logins are avoided; where a platform forces one, access goes through a password manager with multi-factor authentication enabled.
• Access follows the work. People get access to a client’s systems when a project needs it and lose it when the project ends or they move on. Access is reviewed rather than accumulated.
• Managed devices. Working machines use full-disk encryption, automatic screen lock and current operating system updates.
• Confidentiality by contract. Everyone working on a client engagement is bound by confidentiality obligations, and we sign the client’s NDA and data processing agreement where one is required.
• Incidents. If we become aware of a breach affecting a client’s data, we notify that client without undue delay, with what we know, what we have done and what we recommend — and support any notification the law requires of them.

On most engagements we work in systems the client owns. There, the client’s controls take precedence over ours: we follow their access model, their change process and their data handling rules. We will tell you when we think a control is missing or is working against you, but we do not route around it.

Specific to the site you are reading:

• It is served over HTTPS. Its pages are pre-rendered and static — there is no database, no login and no user account behind it.
• It sets no cookies and loads no analytics, advertising or session-recording scripts. Fonts and assets are served from the site’s own origin.
• The contact form transmits only the fields you fill in. It is validated on the server and is not stored in a database on this site. See the Privacy Policy for what happens to it afterwards.

If you believe you have found a security problem in this site or in anything else we run, tell us at info@machware.com.tr with “Security” in the subject line. Useful reports include what you found, where, the steps to reproduce it and what an attacker could do with it.

We aim to acknowledge a report within three business days, tell you what we assess the impact to be, and let you know when it is fixed. We will credit you if you would like to be credited.

We will not pursue a report made in good faith. In return, please stay within the boundaries of good faith while testing: do not run denial-of-service or high-volume automated attacks, do not access, modify or retain data belonging to anyone else, do not use social engineering or physical intrusion, and give us reasonable time to fix the issue before disclosing it publicly. If the vulnerability is in a system we built for a client, report it to us and we will coordinate with the system’s owner — the decision to disclose is theirs.

We do not currently run a paid bug bounty programme.

Machware Teknoloji A.Ş does not currently hold an ISO/IEC 27001 certificate or a SOC 2 report, and we will not imply otherwise. The practices above are what we actually do. If your procurement process needs a certified supplier, a completed security questionnaire, evidence of specific controls, or a penetration test report for a system we built, contact info@machware.com.tr and we will tell you plainly what we can and cannot provide.

No system is perfectly secure, and no page like this one should suggest otherwise. What we commit to is building carefully, saying what we know, and responding quickly when something is wrong.

Security questions, vulnerability reports and supplier assessments all go to info@machware.com.tr. This page was last revised on 4 September 2026.