What you are looking for, best practices style, is AGDLP. Wikipedia has an ok description of it. http://en.wikipedia.org/wiki/AGDLP
The short version is to put people into Universal or Global groups based on their roles and named after the specific role. (Like putting groups Team1 and Team3 to into DataTransferAppUsers.) Then make Domain Local groups for the permissions (group Share_DataTransfer_RW should have Modify access to that share) and then put the universal groups into that share.
Don't be afraid to make the user groups specific and small and then nest them or combine the smaller groups into more general ones. Try to avoid sub-dividing the user groups into more than one or two different hierarchies. Keep people groups apart from role groups, role groups should only have groups in them. Try even harder to avoid EVER putting individual users into the Domain Local permissions groups.
User -> UserGroup -> RoleGroup -> DomainLocalPermissionGroup -> ACL
Now when you add a person you need only get him into a few UserGroups. When you add a new resource for an existing role you create 1 or 2 groups (readonly and/or readwrite) and apply that one role to it. When you create a new role, you just create one group and then look for resources it will use.
You thus use AD to tie everything together. The discipline comes from never, ever applying a User (Account in MS lingo) or Group of user directly to any ACL on a local system. This way you can trust there is nothing going on outside the view of the permission tree you build in AD.
Given a shared folder, \nyc-ex-svr-01\groups\bizdev; a business development group within the organization's Marketing department, represented in Active Directory as the (existing) global security group "Business Development Team Member"; and a requirement that the entire group have read-write access to the shared folder, an administrator following AGDLP might implement the access control as follows:
Create a new domain local security group in Active Directory named "Change permission
on \nyc-ex-svr-01\groups\bizdev".
Grant that domain local group the NTFS "change" permission set (read, write, execute/modify, delete) on the "bizdev" folder. (Note that NTFS permissions are different from share permissions.)
Make the "Business Development Team Member" group a member of the "Change permission on \nyc-ex-svr-01\groups\bizdev" group.
To highlight the advantages of RBAC using this example, if the Business Development Team required additional permissions on the "bizdev" folder, a system administrator would only need to edit a single access control entry (ACE) instead of, in the worst case, editing as many ACEs as there are users with access to the folder.